[Python-Dev] Free threading (original) (raw)

Paul Prescod paulp@ActiveState.com
Tue, 07 Aug 2001 23:29:20 -0700

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