← Back to context

Comment by monocasa

4 years ago

> 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.