RetroSearch Browse

Thu Apr 7 13:21:00 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-April/052563.html

Michael Hudson wrote:
> Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
> Non-invasive, but bleh.

Tim rejected this option back when PyEval_ThreadsInitialized() was added to the 
API [1]. Gustavo was having a similar problem with pygtk, and the end result was 
to add the ThreadsInitialized API so that pygtk could make its own check without 
slowing down the default case in the core.

> Option 2) Call PyEval_SaveThread() instead of
> PyEval_ReleaseThread()[1] in PyGilState_Release().  This is my
> favourite option (PyGilState_Ensure() calls PyEval_RestoreThread which
> is PyEval_SaveThread()s "mate") and I guess you can distill this long
> mail into the question "why doesn't PyGilState_Release do this
> already?"

See above. Although I'm now wondering about the opposite question: Why doesn't 
PyGilState_Ensure use PyEval_AcquireThread?

Cheers,
Nick.

[1] 
http://sourceforge.net/tracker/?func=detail&aid=1044089&group_id=5470&atid=305470
[2] http://mail.python.org/pipermail/python-dev/2004-August/047870.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-April/052563.html below:

[Python-Dev] threading (GilState) question