How a module is being marked as imported?

[Jean-Charles Lefebvre]

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?