Maxime Devos <maximede...@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’.
