4 ms·
Yes waitpid(-1) doesn't compose, but lots of things in the C world don't compose - using library A which uses say libuv, and one that uses libevent (two differ
by chubot 2y ago
Yes waitpid(-1) doesn't compose, but lots of things in the C world don't compose
- using library A which uses say libuv, and one that uses libevent (two different event loops)
- forking while holding locks
- two libraries using two different thread pools -- concurrency policy is a global concern. (and this one isn't specific to C)
FWIW the solution I use in a shell is simple - create a Waiter object that wraps waitpid(), and only code that has a reference to the waiter can do anything with processes.
It's basically like making an event loop object and passing it around, rather than making it global.
This is also an argument for libraries not doing I/O -- they should be pure. They should be parameterized by I/O, including starting threads, etc.
I haven't ever wanted to use a library that starts processes behind my back
- thayne 2y ago> using library A which uses say libuv, and one that uses libevent (two different event loops) It's not ideal, but I don't see a reason this wouldn't work if you ran the two event loops on separate threads > forking while holding locks Yes. You can't use fork in a multi-threaded program, unless it is followed by an exec. Which is one reason forking is somewhat rare in modern code. > two libraries using two different thread pools -- concurrency policy is a global concern. That doesn't break the semantics of the program. > create a Waiter object that wraps waitpid(), and only code that has a reference to the waiter can do anything with processes. This doesn't help if you use a library that calls waitpid directly. This is actually probably more of a problem in non-c code, where the standard library likely to have an abstraction that calls waitpid on child processes. So handling SIGCHLD can interfere with other code waiting for a child to finish.