[Python-Dev] threading (GilState) question

[Michael Hudson]

Tim Peters <tim.peters at gmail.com> writes:

> [Michael Hudson]
>> ...
>> Point the first is that I really think this is a bug in the GilState
>> APIs: the readline API isn't inherently multi-threaded and so it would
>> be insane to call PyEval_InitThreads() in initreadline, yet it has to
>> cope with being called in a multithreaded situation.  If you can't use
>> the GilState APIs in this situation, what are they for?
>
> That's explained in the PEP -- of course <wink>:
>
>     http://www.python.org/peps/pep-0311.html

Gnarr.  Of course, I read this passage.  I think it's missing a use
case.

> Under "Limitations and Exclusions" it specifically disowns
> responsibility for worrying about whether Py_Initialize() and
> PyEval_InitThreads() have been called:
>
[snip quote]

This suggests that I should call PyEval_InitThreads() in
initreadline(), which seems daft.

> That doesn't mean there isn't a clever way to get the same effect
> anyway,

Pah.  There's a very simple way (see my reply to Nick).  It even works
in the case that PyEval_InitThreads() is called in between the call to
PyGilState_Ensure() and PyGilState_Release().

> but I don't have time to think about it, and reassigned the bug
> report to Mark (who may or may not have time).

He gets a week :)

Cheers,
mwh

-- 
  Or here's an even simpler indicator of how much C++ sucks: Print
  out the C++ Public Review Document.  Have someone  hold it about
  three feet  above your head and then drop it.  Thus  you will be
  enlightened.                                        -- Thant Tessman