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
