> Like I've said elsewhere in the comments, I've literally had to fix awful bugs, some security related, from how much vfork() is a preloaded foot gun with the safety off. Not everyone who has a bad impression of it is just following the "lore".
> You're supposed to only use async-signal-safe functions on the child-side of fork().
Not practically, there's way more code out there designed day one for fork(). Next to none designed for vfork() explicitly.
Signal safety has more to do with shared mutability, which isn't a concern for fork. You can get into gross situations mixing fork and threads, but that's equally true of vfork.
> Signal safety has more to do with shared mutability, which isn't a concern for fork.
And yet that's what the spec says about child-side code following fork(). There's a reason for that. It's not just about signals. Async-signal-safe means, yes, that you can use it in an asynchronous signal handler, but there are contexts other than async signal handlers that require async-signal-safe code.
> You can get into gross situations mixing fork and threads...
You can get into bad situations just using fork and no threads.
> Not practically, there's way more code out there designed day one for fork(). Next to none designed for vfork() explicitly.
> And yet that's what the spec says about child-side code following fork(). There's a reason for that. It's not just about signals. Async-signal-safe means, yes, that you can use it in an asynchronous signal handler, but there are contexts other than async signal handlers that require async-signal-safe code.
You cut off with the reason being threads and shared mutability.
In fact that's what the spec says too.
1003.1-2017 on fork()
> A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.
Practically if you don't use threads you can do anything in the child process you can do in the parent. Any env that doesn't support that breaks decades of important Unix software.
And what are you fixing by changing fork to vfork there?
> Practically if you don't use threads you can do anything in the child process you can do in the parent. Any env that doesn't support that breaks decades of important Unix software.
Not true. I mentioned PKCS#11 elsewhere in this post or thread. The PKCS#11 case is more generally about devices, or even TCP and other connections. You can't share, say, a file descriptor connected to an IMAP server (or whatever) between the parent and the child (not without adding synchronization, though that need not mean mutexes).
That's like saying you can't write to the same file willy nilly after any context creation. In context, I obviously meant that you can perform the same actions in the child or the parent, not that you somehow get free synchronization for accessing all kernel objects.
Also, you can specify CKF_INTERFACE_FORK_SAFE if you want a handle in PKCS#11 that handles synchronization enough internally to call from both the child and the parent simultaneously.
fork() -> fork bombs -> fork() is a footgun!
You have to know how to use it. Yes. So what?
> Like I've said elsewhere in the comments, I've literally had to fix awful bugs, some security related, from how much vfork() is a preloaded foot gun with the safety off. Not everyone who has a bad impression of it is just following the "lore".
Links or it didn't happen :)