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 <CAH_1eM2S0p-XeFOV3WyWOzSkwJSL+pi+tT+dFL4t5C3-_OWEqA@mail.gmail.com>
In-reply-to <5214B11D.9020205@cheimes.de>
Content
> 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:
https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers

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
conflict.
"""

More here:
https://groups.google.com/forum/#!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).
History
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