[Python-Dev] Free threading

[Paul Prescod]

Guido van Rossum wrote:
> 
>...
> 
> Yeah, but it's just not worth rewriting all of Python to get rid of
> the GIL for *that*.  

I'm not campaigning against the GIL. That's a separate issue.

I'm asking why all of the Python interpreters in a particular process
have to share *anything*. My naive view is that avoiding process-wide
data is just good practice in any library. Of course processes that WANT
to share data must share a GIL until Python is free-threaded.

For my own understanding I am curious, do "unrelated" Python
interpreters share state:

 a) because that makes the implementation of the Python interpreter
easier or 
 b) because it makes it easier to write extending and embedding apps
(don't have to pass around a context object)?
 c) that's just how it evolved.

> ... There are plenty of other ways to deal with it,
> including pre-forked longer-running processes -- and remember, it's
> only necessary if you need more than one CPU just for running your
> Python code!  (E.g. Zope, which has a perfectly good Zope-specific
> solution if you need multiple CPUs: ZEO.)

Yes, you can always work around it. But any non-reentrant libary can be
worked around. The only difference is that Python is a language so the
library provides an inherent mechanism for working around the issue. I
admit that in most cases this is a strong enough practical argument.

>...
> Good question.  I've never used mmap myself. :-)  I know Unix shared
> memory has locks and semaphores; the mmap module apparently doesn't
> (possibly because Windows has a different philosophy there).

So do you know of any fast, portable mechanism for cross-process
locking? That's the only thing between us and a nice queue-and-marshal
based IPC mechanism!

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook