A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-December/084419.html below:

why not remove thread support instead?

[Python-Dev] The endless GIL debate: why not remove thread support instead? [Python-Dev] The endless GIL debate: why not remove thread support instead?Christian Heimes lists at cheimes.de
Fri Dec 19 00:28:13 CET 2008
Paul Moore schrieb:
> OK, but how close is it to providing isolation for threads running
> under the control of the GIL? I'm thinking of something along the
> lines of an in-process version of fork(), which spawns a new
> interpreter and runs the 2 interpreters as threads, still using the
> GIL to enforce serialisation, but otherwise independent. I believe
> that Perl uses this model for its "interpreter threads"
> implementation.

How is your idea different from subinterpreters? Today you can have
multiple subinterpreters inside a single process. Each subinterpreter
has its own state and can see only its own objects.

Christian

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