Message195786
| 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:14 | neologix | set | recipients: + neologix, barry, georg.brandl, pitrou, vstinner, christian.heimes, benjamin.peterson, python-dev, sbt |
| 2013-08-21 12:45:14 | neologix | link | issue18747 messages |
| 2013-08-21 12:45:13 | neologix | create | |