Comment by ddulaney
4 years ago
Yeah, if you’re never planning on calling exec, vfork doesn’t make much sense.
Can I ask how you approach resource management and dependencies in that kind of code base? As the article briefly mentions, using fork without exec means you need to keep everything else in the process fork-safe, which I know can be a challenge in the presence of third-party code.
Not who you're replying to, but it's trivial as long as you don't use threads.
I suppose third-party code could be opening up file-descriptors behind your back and privately maintaining that state in private storage, but third-party code that does that without documenting it is relatively rare in the Unix/C world in my experience.
Historically getXbyY functions and the name service switch had a way of doing that, and that was one reason for nscd to come along (another was to cache better, naturally).
Most (all?) of the nsswitch functions were datagram based back in the day, so those would be safe.
I've certainly never had issues using e.g. getpwent on a NIS setup with forking and modern rpcbind may use TCP I believe. Maybe it opens a new connection each time?
Static file descriptors were a bit more common in the old days, but look horribly out of place in modern code. Keeping the code fork safe is easier than keeping it thread safe, at least with fork you aren't sharing the heap.
But you're sharing file descriptors, which might be for devices, or for SOCK_SEQ connections, etc, and you can't just have the parent and child step all over each other writing to them. Now, you wouldn't do that, but you might use a library that lets you end up doing that without noticing. Fork-safety is not trivial.