Tim Peters <tim.peters@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>:
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