homepage

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 Alex.Roitman, barry, brett.cannon, eric.araujo, gregory.p.smith, ncoghlan, r.david.murray
Date 2010年08月17日.02:08:40
SpamBayes Score 1.7688727e-08
Marked as misclassified No
Message-id <1282010924.13.0.158310474023.issue9573@psf.upfronthosting.co.za>
In-reply-to
Content
Added Greg to nosy list as the one that fixed issue 7242 with the current _PyImport_ReInitLock semantics.
Also kicking over to Barry regarding implications for 2.6.6 (this is a regression from 2.6.4 due to the resolution of 7242).
7242 was about forking from a *thread*. This is about forking as a side effect of import, which, just like spawning a thread as a side effect of import, can easily cause issues.
The RuntimeError noted by the OP isn't thrown by the fork() call - it is thrown at the end of the import when control is returned to the main module. Completely reinitialising the lock without accounting for the current depth of nesting is incorrect. Instead, I believe ReInitLock should look more like:
 if (import_lock != NULL)
 import_lock = PyThread_allocate_lock();
 if (import_lock_level > 1) {
 /* Forked as a side effect of import */
 long me = PyThread_get_thread_ident();
 import_lock_thread = me;
 import_lock_level--;
 } else {
 import_lock_thread = -1;
 import_lock_level = 0;
 }
(I haven't tested that yet, but will soon)
History
Date User Action Args
2010年08月17日 02:08:44ncoghlansetrecipients: + ncoghlan, barry, brett.cannon, gregory.p.smith, eric.araujo, r.david.murray, Alex.Roitman
2010年08月17日 02:08:44ncoghlansetmessageid: <1282010924.13.0.158310474023.issue9573@psf.upfronthosting.co.za>
2010年08月17日 02:08:42ncoghlanlinkissue9573 messages
2010年08月17日 02:08:40ncoghlancreate

AltStyle によって変換されたページ (->オリジナル) /