Thanks to everyone for the great responses! Below are some notes/discussion on the various replies I've seen:
> If it's supposed to behave as if fork() has been called, this implicitly > includes calling atfork handlers when POSIX_C_SOURCE is defined... Regarding glibc, I'm not sure the POSIX_C_SOURCE macro would control that. Here is a reference to the latest definition of system() in the POSIX standard: https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html The glibc developers had a discussion on this topic here: https://sourceware.org/bugzilla/show_bug.cgi?id=17490 They seemed to go back and forth on this same issue, and one developer suggested communicating the ambiguity with the Austin Group. I'm not sure if this was ever done, but there still appears to be a discrepancy (in system(), popen() -- https://pubs.opengroup.org/onlinepubs/9699919799/functions/popen.html, and maybe others). > Couldn't that be addressed by SO_REUSEADDR? According to https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_10_16, SO_REUSEADDR "indicates that the rules used in validating addresses supplied in a https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html should allow reuse of local addresses". Based on this, it doesn't appear to be for the purposes of addressing this issue, and we're not excited about the other side effects as well. > The reason it likely that the implementer of system() and popen() get the > freedom to use a more efficient mechanism. That might be, but it would be good to document the tradeoffs associated with that efficiency. Even better would be to come up with a mechanism to avoid it entirely. If requiring pthread_atfork() handlers to execute is not an option, then maybe a file-descriptor/socket option that marks the socket as closing once the process forks (like SOCK_CLOEXEC / FD_CLOEXEC, but done at fork() instead of exec()). > The vfork() used before also did not call the pthread_atfork() handlers > either. https://pubs.opengroup.org/onlinepubs/009604599/functions/vfork.html comes with a lot of warnings, an explicit recommendation to use fork(), and a note that it may be withdrawn in the future. As such we weren't as worried about it, but maybe we should be... > If you have control over the callers of system() We don't have control over them, which makes this more disconcerting. Cheers, Nate ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
