Change Details

Described in [1], signal handlers running in a vfork child have opportunities to corrupt the parent's state. posix_spawn should handle this by blocking all signals before vfork(2) then resetting all signal handlers in the child before restoring the old signal mask. Some level of tracking signals that might have handlers has been added to sigaction; this isn't expected to be completely accurate, just a heuristic that we use to reduce the number of syscalls required to reset non-default signal handlers. Addressing this has been identified as a prerequisite to using posix_spawn in subprocess on FreeBSD [2]. [1] https://ewontfix.com/7/ [2] https://bugs.python.org/issue35823 [side note] I contemplated pushing the signal reset bits further down into the vfork child and doing them as we're processing spawnattr (and something similar to the current approach if `sa == NULL`), but I wasn't sure if the added complexity was worth the trade-off.

Described in [1], signal handlers running in a vfork child have opportunities to corrupt the parent's state. Address this by adding a new rfork(2) flag, RFSPAWN, that has vfork(2) semantics but also resets signal handlers in the child during creation. x86 uses rfork_thread(3) instead of a direct rfork(2) because rfork w/ RFMEM/RFSPAWN cannot work when the return address is stored on the stack -- further information about this problem is described under RFMEM in the rfork(2) man page. Addressing this has been identified as a prerequisite to using posix_spawn in subprocess on FreeBSD [2]. [1] https://ewontfix.com/7/ [2] https://bugs.python.org/issue35823

Described in [1], signal handlers running in a vfork child have opportunities to corrupt the parent's state. posix_spawn should handle this by blocking all signals beforeAddress this by adding a new rfork(2) flag, RFSPAWN, that has vfork(2) then resetting allsemantics but also resets signal handlers in the child before restoduring the old signal maskcreation. Some level of tracking signals that might have handlers has been added to sigaction; this isn't expected to be completely accurate, just a heuristic that we use to reduce the number of syscalls required to reset non-default signal handlersx86 uses rfork_thread(3) instead of a direct rfork(2) because rfork w/ RFMEM/RFSPAWN cannot work when the return address is stored on the stack -- further information about this problem is described under RFMEM in the rfork(2) man page. Addressing this has been identified as a prerequisite to using posix_spawn in subprocess on FreeBSD [2]. [1] https://ewontfix.com/7/ [2] https://bugs.python.org/issue35823 [side note] I contemplated pushing the signal reset bits further down into the vfork child and doing them as we're processing spawnattr (and something similar to the current approach if `sa == NULL`), but I wasn't sure if the added complexity was worth the trade-off.