[Python-Dev] threading (GilState) question (original) (raw)

Michael Hudson mwh at python.net
Thu Apr 7 14:27:16 CEST 2005

Nick Coghlan <ncoghlan at gmail.com> writes:

Michael Hudson wrote:

Option 1) Call PyEvalThreadsInitialized() in PyGilStateRelease(). Non-invasive, but bleh. Tim rejected this option back when PyEvalThreadsInitialized() was added to the API [1].

Well, not really. The patch that was rejected was much larger than any proposal of mine. My option 1) is this:

--- pystate.c 09 Feb 2005 10:56:18 +0000 2.39 +++ pystate.c 07 Apr 2005 13:19:55 +0100
@@ -502,7 +502,8 @@ PyThread_delete_key_value(autoTLSkey); } /* Release the lock if necessary */

} #endif /* WITH_THREAD */

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.

Well, Gustavo seemed to be complaining about the cost of the locking. I'm complaining about crashes.

Option 2) Call PyEvalSaveThread() instead of PyEvalReleaseThread()[1] in PyGilStateRelease(). This is my favourite option (PyGilStateEnsure() calls PyEvalRestoreThread which is PyEvalSaveThread()s "mate") and I guess you can distill this long mail into the question "why doesn't PyGilStateRelease do this already?"

This option corresponds to this patch:

--- pystate.c 09 Feb 2005 10:56:18 +0000 2.39 +++ pystate.c 07 Apr 2005 13:24:33 +0100
@@ -503,6 +503,6 @@ } /* Release the lock if necessary */ else if (oldstate == PyGILState_UNLOCKED)

} #endif /* WITH_THREAD */

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

Well, that would make more sense than what we have now. OTOH, I'd much rather make the PyGilState functions more tolerant -- I thought being vaguely easy to use was part of their point.

I fail to believe the patch associated with option 2) has any detectable performance cost.

Cheers, mwh

-- People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. -- Linus Torvalds

More information about the Python-Dev mailing list