bug#56674: [Shepherd] Use of ‘waitpid’, ‘system*’, etc. in service code can cause deadlocks

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Why Shepherd and not guile fibers? Is this a Shepherd-specific problem?

Blocking calls are a problem for Fibers in general, and ‘waitpid’ is no
exception.

The problem here is Shepherd-specific in the sense that we’re more
likely to use ‘system*’ and ‘waitpid’ in this context.  It’s also
Shepherd-specific because shepherd already runs an event loop that
tracks signal FDs and will thus “see” SIGCHLD events.

> 3. Make waitpid (or a variant that does what we need) interact well
> with guile-fibers, like how 'accept' is doesn't inhibit switching to
> another fiber. There some Linux API with signal handlers or pid fds or
> such that might be useful here, though I don't recall the
> name. Presumably something similar can be done for the Hurd, though
> some C glue may be needed to access the right Hurd APIs if the signal
> handler API isn't portable.

Yes, that’s roughly what I had in mind when I mentioned providing a
replacement for ‘system*’ (but you’re right, it’s a replacement for
‘waitpid’ at its core).

> Alternatively:
>
> 4. Do the waitpid in a separate thread (needs work-around for the
> multi-threaded fork problem, probably C things? Or modifying Guile and
> maybe glibc to avoid async-unsafe things or make more things
> async-safe or whatever the appropriate ...-safe is here.)

For shepherd, multithreading is not an option due to the semantics of
fork in the presence of threads.

Ludo’.