[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Tal Einat added the comment: I am able to reproduce this with Python 3.6.3 and 3.7.0, but not with 3.7.4, 3.8.0b3 or current master (to be 3.9). This has been fixed since 3.7.3; see issue #34572. -- nosy: +taleinat resolution: not a bug -> fixed stage: -> resolved status: pending ->

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Changes by Serhiy Storchaka : -- resolution: -> not a bug status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka type: crash -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Brett Cannon added the comment: I just checked and this is no longer an issue in Python 3.3. The sys.modules "bug" isn't a bug as that's how it is supposed to work to prevent partially initialized modules. As for how pickle is doing stuff, that could change if it wouldn't break backwards-compa

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Changes by Chris Kaynor : -- nosy: +DragonFireCK ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Sagiv Malihi added the comment: As I said - it certainly happenes on 3.2 (tested). @pitrou - what you suggested will not work since the actual import will block on the import lock. The optimization there is not needed, it's already implemented in __import__. -- __

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Antoine Pitrou added the comment: > PyImport_ExecCodeModuleEx adds the module to sys.modules *before* > actually executing the code. This is a design flaw (can it really be > changed? ) I guess it is done so to allow for circular imports. > The second bug: in cPickle.c: func_class() > cPickle

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Changes by R. David Murray : -- nosy: +brett.cannon, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

Sagiv Malihi added the comment: OK, digging deeper reveals that there are actually two bugs here, one is conceptual in the python importing mechanism, and the other is technical in cPickle. The first bug: PyImport_ExecCodeModuleEx adds the module to sys.modules *before* actually executing t

[issue12680] cPickle.loads is not thread safe due to non-thread-safe imports

New submission from Sagiv Malihi : When trying to cPickle.loads() from several threads at once, there is a race condition when threads try to import modules. An example will explain it best: suppose I have module foo.py which takes some time to load: import time class A(object): def __sets