This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients barry, benjamin.peterson, christian.heimes, georg.brandl, neologix, pitrou, python-dev, sbt, vstinner
Date 2013-08-21.12:45:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> Which part of the function is not async-signal safe? It doesn't interact
> with any file descriptors nor does it use any syscalls except for
> getpid() and time().

gettimeofday() and RAND_add()

The functions which are guaranteed to be async-signal safe are listed here:

And here's what David Butenhof says about pthread_atfork():
The real answer is that pthread_atfork() is a completely useless and stupid
mechanism that was a well intentioned but ultimately pointless attempt to
carve a "back door" solution out of an inherently insoluable design

More here:!msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ

IMO it's really an openssl issue, and it should be fixed there (mainly
because they are the only one in position of setuping a safe
atfork-hook, like the glibc does for malloc & co).
Date User Action Args
2013-08-21 12:45:14neologixsetrecipients: + neologix, barry, georg.brandl, pitrou, vstinner, christian.heimes, benjamin.peterson, python-dev, sbt
2013-08-21 12:45:14neologixlinkissue18747 messages
2013-08-21 12:45:13neologixcreate