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

2019-08-05 Thread Tal Einat
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

2017-06-18 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- resolution: -> not a bug status: open -> pending ___ Python tracker ___

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

2017-02-19 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka type: crash -> behavior ___ Python tracker ___

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

2012-11-12 Thread Eric Snow
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12680 ___ ___ Python-bugs-list

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

2012-09-12 Thread Brett Cannon
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

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

2012-09-11 Thread Chris Kaynor
Changes by Chris Kaynor ckay...@zindagigames.com: -- nosy: +DragonFireCK ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12680 ___ ___

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

2011-08-09 Thread Sagiv Malihi
Sagiv Malihi sagivmal...@gmail.com 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

2011-08-05 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr 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()

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

2011-08-02 Thread Sagiv Malihi
New submission from Sagiv Malihi sagivmal...@gmail.com: 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

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

2011-08-02 Thread Sagiv Malihi
Sagiv Malihi sagivmal...@gmail.com 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*

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

2011-08-02 Thread R. David Murray
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +brett.cannon, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12680 ___ ___