Comment by ddulaney
4 years ago
vfork halts the parent until the child exits or calls exec, getting its own address space. In the normal case, you vfork and immediately exec, and the parent continues on with what it was doing. The time between vfork and exec is “special” in that the child is temporarily running in the parent’s address space, then it uses exec to separate and do its own thing.
Ah, that makes a lot more sense.
I must be weird in that I almost never use exec() after a fork().
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.
2 replies →
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.
1 reply →