Re: unifying mcron and shepherd, service woes, improvements

[Philip McGrath]

On 5/15/21 12:59 PM, Ludovic Courtès wrote:
> raingloom <raingloom@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