February update on the Guile guix-daemon

February update on the Guile guix-daemon

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

Hey!

Here's an overdue update on rewriting the Guix daemon in Guile,
following on from the earlier thread on guix-devel [1] and the blog post
[2].

1: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00328.html
2: https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/

Unfortunately I was quite slow to actually get stuck in with the
code. Among other things, I've been distracted by trying to at least
work around long running issues with the build coordinator and data
service. I wanted to try and get QA back up and running and reduce the
number of times that manual intervention is required, and this has been
successful to some extent. I'm going to try harder to focus on the
guix-daemon in the coming months however.

With the time I have managed to spend working on the daemon though, I
think I've made some progress. I started by getting a process to listen
on a socket, then worked through implementing operations used by guix
build (with many simplifying assumptions that is).

This has given me some assurances about the viability of the technical
plan I outlined in the blog post, as well as filling in some of the
details.

These are my current thoughts about the work ahead:

 - I've sent a couple of patch series [3][4] to adapt parts of Guix for
   use in the daemon, there'll need to be more changes in the database
   and substitute areas though.

 - I'm starting to understand, test and adapt the work on the
   guile-daemon branch, but there's more that needs doing on this.

 - Then there's the big areas to work on next:

   - I think I'm going to need to use thread pools for SQLite operations
     in the daemon, as the build coordinator does.

   - There's the low level work of setting up the build environment, the
     work on the guile-daemon branch helps a lot with this, but as
     pointed out by Ludo, there might be some issues with fork and
     similar operations in a Guile program using threads.

   - While I've implemented some of the server side protocol used by the
     daemon, I'd like to extract that code in to a module so that it's
     not wrapped up inside the daemon script

3: https://issues.guix.gnu.org/69291
4: https://issues.guix.gnu.org/69292

I think once I've made more progress in the above areas, I will
hopefully have something that people could attempt to use in a limited
capacity.

Let me know if you have any comments or questions,

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: February update on the Guile guix-daemon

[Ludovic Courtès]

Hello!

Thanks for the update!

Christopher Baines <mail@cbaines.net> skribis:

>  - Then there's the big areas to work on next:
>
>    - I think I'm going to need to use thread pools for SQLite operations
>      in the daemon, as the build coordinator does.

I think we should refrain from using POSIX threads directly and instead
use Fibers to its full extent.  In this case, I’d use a resource pool as
done in Cuirass (and in the Coordinator too, no? maybe that’s what you
meant?).

>    - There's the low level work of setting up the build environment, the
>      work on the guile-daemon branch helps a lot with this, but as
>      pointed out by Ludo, there might be some issues with fork and
>      similar operations in a Guile program using threads.

Right.  I think one of the things we discussed in Brussels is that,
since SQLite operations might block for a while, the daemon will have to
be multithreaded.  Which means no fork/clone, which in turn probably
means delegating forking/cloning to a separate helper process.  (That’s
also what bubblewrap does, IIUC.)

>    - While I've implemented some of the server side protocol used by the
>      daemon, I'd like to extract that code in to a module so that it's
>      not wrapped up inside the daemon script

Wo0t!

Cheers,
Ludo’.

Re: February update on the Guile guix-daemon

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Christopher Baines <mail@cbaines.net> skribis:
>
>>  - Then there's the big areas to work on next:
>>
>>    - I think I'm going to need to use thread pools for SQLite operations
>>      in the daemon, as the build coordinator does.
>
> I think we should refrain from using POSIX threads directly and instead
> use Fibers to its full extent.  In this case, I’d use a resource pool as
> done in Cuirass (and in the Coordinator too, no? maybe that’s what you
> meant?).
>
>>    - There's the low level work of setting up the build environment, the
>>      work on the guile-daemon branch helps a lot with this, but as
>>      pointed out by Ludo, there might be some issues with fork and
>>      similar operations in a Guile program using threads.
>
> Right.  I think one of the things we discussed in Brussels is that,
> since SQLite operations might block for a while, the daemon will have to
> be multithreaded.  Which means no fork/clone, which in turn probably
> means delegating forking/cloning to a separate helper process.  (That’s
> also what bubblewrap does, IIUC.)

I've had a bit more of a think and have thought of some more things we
can try, but I'm still not sure if it can be made to work.

We can call (sleep 0) after every sqlite-step to allow other fibers to
run if they're able to [1] and if we find places where sqlite-step takes
too long, maybe we can use a short lived thread for this, but then make
sure these threads have stopped before doing anything where they would
cause problems (e.g. fork/clone).

1: https://github.com/wingo/fibers/wiki/Manual#31-blocking

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]