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 ncoghlan
Recipients belopolsky, brett.cannon, christian.heimes, grahamd, ncoghlan
Date 2010-07-12.15:19:26
SpamBayes Score 1.16101e-06
Marked as misclassified No
Message-id <1278947968.72.0.70811280143.issue8098@psf.upfronthosting.co.za>
In-reply-to
Content
Interesting. Your example code doesn't run afoul of any of the "don't do this" flags relating to import that I put into the threading docs, so it seems like a fair complaint to me.

As Christian pointed out on c.l.p, the idea with this API is to turn deadlocks triggered due to violations of the first rule noted in http://docs.python.org/library/threading.html#importing-in-threaded-code into exceptions instead. This is *much* friendlier than the old behaviour.

However, as your example shows, there are cases involving the main module where the new approach will throw an exception but a deadlock would not have occurred if it had just waited for the import lock to be released.

Note the difference in behaviour if the invocation style is changed to hold the import lock when the module is executed:

$ ./python -c "import noblock"
acquire
strptime
exit
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

(The bizarre exception noise at the end is due to the violation of rule 2 at the page linked above - since the example code used thread rather than threading, we tried to release an import lock that didn't exist any more. If the code had used threading instead it would have worked fine and printed "released" as expected)

My instinct says that allowing *_NoBlock() to block(!) when invoked from the main Python thread will "do the right thing", but I'm going to want to ponder that for a while. Inadvertently recreating the deadlocks that this whole mechanism is designed to eliminate would be dumb.
History
Date User Action Args
2010-07-12 15:19:28ncoghlansetrecipients: + ncoghlan, brett.cannon, belopolsky, christian.heimes, grahamd
2010-07-12 15:19:28ncoghlansetmessageid: <1278947968.72.0.70811280143.issue8098@psf.upfronthosting.co.za>
2010-07-12 15:19:27ncoghlanlinkissue8098 messages
2010-07-12 15:19:26ncoghlancreate