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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4