Message195784
| Author | christian.heimes |
|---|---|
| Recipients | barry, benjamin.peterson, christian.heimes, georg.brandl, neologix, pitrou, python-dev, sbt, vstinner |
| Date | 2013-08-21.12:22:54 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <5214B11D.9020205@cheimes.de> |
| In-reply-to | <CAH_1eM31NVvvy=rgbX8HNdDtW=3wu6MehPQydyfiz=fVHchSEA@mail.gmail.com> |
| Content | |
|---|---|
Am 21.08.2013 14:08, schrieb Charles-François Natali: > And basically, because PySSL_RAND_atfork_child() is not async-signal > safe, the interpreter is now subject to random deadlocks/crash in > multi-threaded processes. I personally don't consider this a security > fix... 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(). Python's _ssl module doesn't re-initialize its locks on fork. That's an outstanding issue that is not related to the change. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2013-08-21 12:22:55 | christian.heimes | set | recipients: + christian.heimes, barry, georg.brandl, pitrou, vstinner, benjamin.peterson, neologix, python-dev, sbt |
| 2013-08-21 12:22:55 | christian.heimes | link | issue18747 messages |
| 2013-08-21 12:22:54 | christian.heimes | create | |