So far, I've been advised to: 1/ Double-check that the GIL was correctly acquired 2/ Ensure there's no 'string' module in my project 3/ Manually pre-import commonly used standard modules at interpreter's init-time to avoid race conditions due to the multi-threaded nature of the running environment
No problem found for 1/ & 2/ (double-checked). I tried 3/ before posting and could not reproduce the problem at all which is probably the patch I will apply due to the lack of a better solution. I guess I'll have to dig into __import__'s code and related. On Thursday, February 4, 2016 at 11:20:05 AM UTC+1, Jean-Charles Lefebvre wrote: > Hi all, > > The short version: How CPython marks a module as being fully imported, if it > does, so that the same import statement ran from another C thread at the same > time does not collide? Or, reversely, does not think the module is not > already fully imported? > > The full version: I'm running CPython 3.5.1, embedded into a C++ application > on Windows. The application is heavily multi-threaded so several C threads > call some Python code at the same time (different Python modules), sharing > interpreter's resources by acquiring/releasing the GIL frequently DURING the > calls, at language boundaries. > > Sometimes (but always only once per application instance), a call to > os.path.expandvars raises the AttributeError exception with message: module > 'string' has no attribute 'ascii_letters'. It is raised by the > ntpath.expandvars function (line 372). When I noticed the late import > statement of the 'string' module at the line above, I thought that MAYBE, it > could be because the interpreter is ran in an heavily multi-threaded > environment and that the GIL acquiring/releasing occurred at a bad timing? > Making me wonder how the import mechanism interacts with the GIL, if it does? -- https://mail.python.org/mailman/listinfo/python-list
