On Fri, 4 Apr 2025, Takashi Yano wrote: > On Fri, 4 Apr 2025 16:17:21 +0200 (CEST) > Johannes Schindelin wrote: > > But that means that the `signal_arrived` that is copied from the parent > > process should be invalidated in the child processes, right? > > Yes. > > The 'value' of the handle is copied by child_copy() because the process > is forked, however, the handle itslef is not validated because the handle > is created by: > signal_arrived = CreateEvent (NULL, false, false, NULL); > (i.e. lpEventAttributes is NULL) > > [in, optional] lpEventAttributes > A pointer to a SECURITY_ATTRIBUTES structure. If this parameter is NULL, > the handle cannot be inherited by child processes.
One bit of info was missing from that reply: the 'value' of signal_arrived is 'invalidated in the child process' by fixup_after_fork, hence why moving pthread::atforkchild later in that function seems like the correct fix. I think anything which runs user callbacks should be late enough in that function that it can be assured that if the callback calls any cygwin dll functions, they will work just as well as if they were called after fork returned 0. (The man page for pthread_atfork on Linux says: > After a fork(2) in a multithreaded process returns in the child, the > child should call only async-signal-safe functions (see sig‐ > nal-safety(7)) until such time as it calls execve(2) to execute a new > program. Note that pthread_atfork doesn't necessarily imply a multithreaded process though, it's just that pthread happened to be the part of POSIX that specified a callback mechanism for fork (opensc used it to make sure the forked child did not inherit the active session to the smartcard, for security purposes. They probably could have used O_CLOFORK if it existed at the time).
