This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Windows deadlock with PyEval_ReleaseLock
Type: behavior Stage: test needed
Components: Windows Versions: Python 3.1, Python 3.2, Python 2.7
Status: closed Resolution: duplicate
Dependencies: Superseder: PyGILState_Ensure does not acquires GIL
View: 1720250
Assigned To: Nosy List: BreamoreBoy, amaury.forgeotdarc, montulli
Priority: normal Keywords:

Created on 2005-02-22 19:04 by montulli, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg60673 - (view) Author: Lou Montulli (montulli) Date: 2005-02-22 19:04
This problem is described well by this post from '03

The problem still seems to exist.  The solution
described within the post will not work in all cases
because if you do not call  PyEval_ReleaseLock then
other threads will be deadlocked, and if you do call
PyEval_ReleaseLock, the thread that originally called
InitThreads will be deadlocked.  The only work around
that I have found so far is to use a separate thread
that will never call scripts call InitThreads and then
 PyEval_ReleaseLock.  After that all threads will run
correctly, but the thread that originally called
InitThreads cannot run python.

Feel free to contact me for any other details, or call
me a bonehead if I screwed something up.  lou a
montulli o org
msg109747 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-09 15:10
Anyone with Windows threading experience who could comment on this please, i.e. is it still an issue?
msg109765 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-07-09 16:38
This issue looks invalid to me: PyEval_ReleaseLock manipulates the interpreter lock, but not the thread state.
Both have to be released/reset before another thread can install its own thread state and run.

In other words, PyEval_SaveThread() should be used instead (and PyEval_RestoreThread() at the end, but the example code does not care to finalize the interpreter)
msg109830 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-07-10 07:32
This is actually the same issue as issue1720250
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41614
2010-07-10 07:32:02amaury.forgeotdarcsetstatus: open -> closed
resolution: duplicate
superseder: PyGILState_Ensure does not acquires GIL
messages: + msg109830
2010-07-09 16:38:01amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg109765
2010-07-09 15:10:54BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2010-07-09 15:10:14BreamoreBoysetnosy: + BreamoreBoy
messages: + msg109747
2009-02-16 01:01:10ajaksu2settitle: Windows deadlock with PyEval_ReleaseLock -> Windows deadlock with PyEval_ReleaseLock
stage: test needed
type: behavior
versions: + Python 2.6, - Python 2.4
2005-02-22 19:04:55montullicreate