3 ms·

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

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.

aidenn0 5y ago
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.
- cryptonector 5y ago
  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).
  - aidenn0 5y ago
    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?
jandrese 5y ago
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.
- cryptonector 5y ago
  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.

3 ms·

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

by ddulaney 5y ago

aidenn0 5y ago
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.
- cryptonector 5y ago
  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).
  - aidenn0 5y ago
    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?
jandrese 5y ago
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.
- cryptonector 5y ago
  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.