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 Martijn.van.Oosterhout, glaubich, neologix, pitrou
Date 2012-01-28.14:40:27
SpamBayes Score 8.881784e-16
Marked as misclassified No
Message-id <1327761629.58.0.276254762892.issue13817@psf.upfronthosting.co.za>
In-reply-to
Content
And here's the test.
To sum up:
- reinit_tls.diff makes sure to call PyThread_ReInitTLS() at the beginning of PyOS_AfterFork(), so that the TLS API is usable within PyOS_AfterFork() (e.g. in _after_fork()). It would be applied to 3.2 and default, even though they are not affected (at least on platform withs a native TLS implementation)
- reinit_tls_test.diff would be applied to 2.7, 3.2 and default: it should not trigger a failure on any of the active branches (2.7, 3.2 and default), it's just to prevent potential future regressions.
Notes regarding the test:
- I replaced subprocess with bare fork(), since it's way cheaper than spawning an entire subprocess
- I reduced the number of threads compared to Christoph's reproducer, because I feel uncomfortable forking up to 1024 processes in parallel (even though in practise they won't be that much, because child processes will terminate before the other threads call fork())
- even with 2.7.2, it won't deadlock 100%, since the race window is really short (but having a failure on one of the buildbots once would be enough to detect the problem, should it ever resurface)
History
Date User Action Args
2012-01-28 14:40:29neologixsetrecipients: + neologix, pitrou, Martijn.van.Oosterhout, glaubich
2012-01-28 14:40:29neologixsetmessageid: <1327761629.58.0.276254762892.issue13817@psf.upfronthosting.co.za>
2012-01-28 14:40:28neologixlinkissue13817 messages
2012-01-28 14:40:28neologixcreate