[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

2022-03-21 Thread Sebastian Berg
Sebastian Berg added the comment: Thanks, so there should already be a lock in place (sorry, I missed that). But somehow we seem to get around it? Do you know what may cause the locking logic to fail in this case? Recursive imports in NumPy itself? Or Cython using low-level C-API? I.e.

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

2022-03-21 Thread Christian Heimes
Christian Heimes added the comment: Python used to have a global import lock. The global import lock prevented recursive imports from other threads while the current thread was importing. The import lock was source of issues and dead locks. Antoine replaced it with a fine grained import

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

2022-03-21 Thread Sebastian Berg
Sebastian Berg added the comment: To add to this: it would seem to me that the side-effects of importing should be guaranteed to only be called once? However, IO or other operations could be part of the import side-effects and release the GIL. So even a simple, pure-Python, package could

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

2022-03-21 Thread Jens Henrik Goebbert
New submission from Jens Henrik Goebbert : While using [Xpra](https://github.com/Xpra-org/xpra) we came across a bug which might be a Python or a NumPy issue. Perhaps some of you can help us understanding some internals. Calling `import numpy` at the same time in two different threads of the