Both system() and popen() will, nearly immediately, exec() completely new processes. Under many circumstances, the new processes will not interact with objects maintained by any registered pthread_atfork() handlers. Any work those handlers do will, in those cases, be completely wasted as a result of the exec(). That is one argument against your proposed solution.
I doubt this is "undefined" by accident. In other words, I doubt this is a defect. If there's no discussion in rationale, I could see that being a defect, but defects in non-normative text are, by definition, not actually defects. The way to proceed, I believe, is for a portable application to provide its own implementations of system() and popen() which provide precisely the semantics required by that application. Open source implementations of both system() and popen() are readily available and can be altered to call your pthread_atfork() handlers as you see fit, without regard to what the platform's implementation might, or might not, do. From: Schwarz, Konrad <konrad.schw...@siemens.com> Sent: Thursday, January 2, 2020 5:00 AM To: Karstens, Nate <nate.karst...@garmin.com>; austin-group-l@opengroup.org Subject: [EXTERNAL] RE: system() and pthread_atfork() > -----Original Message----- > From: Karstens, Nate > <nate.karst...@garmin.com<mailto:nate.karst...@garmin.com>> > Sent: Thursday, December 19, 2019 12:26 AM > To: austin-group-l@opengroup.org<mailto:austin-group-l@opengroup.org> > Subject: system() and pthread_atfork() > > The current definition of system() does not define if the pthread_atfork() > handlers are called. We ran into a > scenario where this caused a problem and wanted to share it with the mailing > list to better understand why those > handlers are not required and get some advice on how best to proceed. I think the right solution is for POSIX to require system() and popen() to call pthread_atfork() handlers. I haven't noticed any arguments against such a solution and it clearly fills a need. I suggest you open a corresponding defect report on http://austingroupbugs.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Faustingroupbugs.net%2Fview.php%3Fid%3D1306&data=02%7C01%7Cjason.zions%40microsoft.com%7Cdea2ea0f24054ec1fb6d08d78f84020c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637135669478802830&sdata=UteAhiMJC4LQ%2BFbZDG%2FZ%2FwWzf5miW8OhA8iguFMs7iA%3D&reserved=0>
