On 5/15/21 12:59 PM, Ludovic Courtès wrote:
raingloom <raingl...@riseup.net> skribis:
Or is everyone else happy with the current design and it's just me who
can't use Shepherd properly? 😅
I think it’s fair to say it’s rough on the edges. :-)
One thing that’s on the to-do list is switching to a real event loop in
lieu of the current ad-hoc blocking design (this was discussed recently
on this mailing list). The switch to ‘signalfd’ in the last release in
a step in that direction. This will unlock “socket activation” and
possibly timers as you mentioned.
From a newcomer's perspective---I haven't used shepherd at all yet---I
was surprised by the discussion leading up to
<https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00396.html>:
On 3/19/21 10:42 PM, raid5atemyhomework wrote:
> Perhaps the point is not so much to be *multi-threaded* but to be
*concurrent*
From very occasionally reading Andy Wingo's blog, I understand that
Guile has a Concurrent ML implementation:
<https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml>.
I haven't programmed with it in Guile at all, but, from my experience
using Racket's Concurrent ML system, I think it is the right foundation
for a supervisor daemon. CML provides a consistent, extensible way to
express, "when something happens, do some action", where "something
happens" might be:
* a timer fires;
* a service, or a set of them, come up;
* a subprocess exits (successfully or not);
* a file descriptor is ready for reading and/or writing;
* a "green thread" (IIUC, a Guile "fiber") has an uncaught exception;
* a signal is received from the OS kernel;
* a user sends a command from the client program;
... etc, etc, etc. The CML implementation handles many low-level details
that are easy to get wrong.
-Philip
