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
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