A RetroSearch Logo

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

Search Query:

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

[Python-Dev] threading (GilState) question

[Python-Dev] threading (GilState) question [Python-Dev] threading (GilState) questionBob Ippolito bob at redivi.com
Sat Apr 9 22:54:30 CEST 2005
On Apr 9, 2005, at 11:15 AM, Michael Hudson wrote:

> "Gregory P. Smith" <greg at electricrain.com> writes:
>
>>>> 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.
>>
>> fwiw, Modules/_bsddb.c does exactly that.
>
> Interesting.  The problem with readline.c doing this is that it gets
> implicitly imported by the interpreter -- although only for
> interactive sessions.  Maybe that's not that big a deal.  I'd still
> prefer to change the functions (would updating the PEP be in order
> here?  Obviously, I'd update the api documentation).

Is there a good reason to *not* call PyEval_InitThreads when using a 
threaded Python?  Sounds like it would just be easier to implicitly 
call it during Py_Initialize some day.

-bob

More information about the Python-Dev mailing list

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