On 01/17/2012 03:57 AM, Jamie Lokier wrote: > You're right, but it looks like it may be removed in the next edition: > > https://www.opengroup.org/austin/docs/austin_446.txt > >> it was only pthread_atfork() which was removed. > > I didn't think pthread_atfork() ever was async-signal-safe. > >> That is, fork() is _required_ >> to be async-signal-safe (and usable from signal handlers), provided that >> the actions following the fork also follow safety rules. > > Nonethless, Glibc fork() isn't async-signal-safe even if it should be: > > http://sourceware.org/bugzilla/show_bug.cgi?id=4737
Thanks for the (depressing) pointers. You posted the link to the Austin Group meeting where fork() was discusses; here's a further link to the actual defect and resolution, which is that the next version of POSIX _will_ be removing fork() from the list of async-signal-safe functions, by replacing it with _Fork() which does _not_ call any of the pthread_atfork() handlers: http://austingroupbugs.net/view.php?id=62 You are right that the only reason that fork() is not signal-safe is because of pthread_atfork(), so I was almost right in my above characterization that pthread_atfork() was the culprit. Maybe we should start probing at configure time whether _Fork already exists, and if so, use it instead of fork(). -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature