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 kristjan.jonsson
Recipients amaury.forgeotdarc, kristjan.jonsson, loewis, mhammond
Date 2009-01-19.17:45:19
SpamBayes Score 3.3272274e-12
Marked as misclassified No
Message-id <1232387121.18.0.400542036598.issue4804@psf.upfronthosting.co.za>
In-reply-to
Content
I understand thread-safe.  This usage is safe from Python threads 
because it is all done in the context of the GIL.

It is, however, unsafe if some other random thread is also modifying 
these settings during runtime.

In your example, T2 doesn't hold the GIL and so, this is the scenario 
that I believe you are invoking.

This is however not likely to be the case because these settings are 
normally left alone.  The only reason we have to worry about this is 
because we are allowing through file descriptors that are out of the 
control of compiled C code.  Nobody is likely to be messing with this 
stuff except for us.

Furthermore, since your argument assumes a rogue thread modifying the 
CRT settings, this thread may just as well be active during startup 
when we are modifying these values under the current system.  So there 
is not a fundamental difference here, only a difference in scale.

I think that the drawbacks of modifying the CRT behaviour unexpectedly 
for all code in the process far outweigh the risk of there being 
another unknown thread also heavily modifying these obscure settings.

Now, I can see a compromise we could make.  I could make this a compile 
time choice.
History
Date User Action Args
2009-01-19 17:45:21kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, mhammond, amaury.forgeotdarc
2009-01-19 17:45:21kristjan.jonssonsetmessageid: <1232387121.18.0.400542036598.issue4804@psf.upfronthosting.co.za>
2009-01-19 17:45:20kristjan.jonssonlinkissue4804 messages
2009-01-19 17:45:19kristjan.jonssoncreate