RetroSearch Browse

Thu Apr 7 17:21:39 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-April/052566.html

[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).

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-April/052566.html below:

[Python-Dev] threading (GilState) question