Charles-François Natali added the comment: > 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18747> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
