[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
Under "Limitations and Exclusions" it specifically disowns
responsibility for worrying about whether Py_Initialize() and
PyEval_InitThreads() have been called:
This API will not perform automatic initialization of Python, or
initialize Python for multi-threaded operation. Extension authors
must continue to call Py_Initialize(), and for multi-threaded
applications, PyEval_InitThreads(). The reason for this is that
the first thread to call PyEval_InitThreads() is nominated as the
"main thread" by Python, and so forcing the extension author to
specify the main thread (by forcing her to make this first call)
removes ambiguity. As Py_Initialize() must be called before
PyEval_InitThreads(), and as both of these functions currently
support being called multiple times, the burden this places on
extension authors is considered reasonable.
That doesn't mean there isn't a clever way to get the same effect
anyway, but I don't have time to think about it, and reassigned the
bug report to Mark (who may or may not have time).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
