Guido van Rossum wrote: > >... > > Anyway, I don't see the point: if you want two 100% independent > interpreters, you can get that easily by forking two separate > processes. That's what separate processes are *for*... I am 95% in agreement with you and that's what I told the Perl guys. That's why I see their "ithreads" solution as a little weird. But the other 5% is when you are running in an already-threaded environment and it is only the Python stuff that you want to be separate (for performance). e.g. Apache, IIS, Sendmail, COM etc. Also, Windows doesn't have "fork" so spawning a process means actually running an executable from disk AFAIK. That's somewhat inefficient. But I'll repeat that in the big picture I agree with you. The combination of shared-data threads and independent-data processes is good enough for most real-world apps. >... > I bet the level of sharing exposed here can be implemented easily on > top of the mmap module. Please excuse my ignorance: how do you do locking in an mmap solution? >... > That sounds to me a quicker road to an efficient SMP solution than > trying to get rid of the GIL. That's why I mentioned it. For whatever reason, the GIL project seems to only be doable by Greg S. (or he's the only one with interest?) so I thought a new approach might catch someone's interest. Does your mild statement of approval indicate that you see the benefit of having independent in-process interpreters? Or are you still thinking about using real processes? If the former, it still seems that the interpreter itself needs a little work so that it is safely reentrant in the sense of any other C library. There especially needs to be a way to NOT share a GIL and NOT share any other mutable data. If you are talking about real processes, then "all" that's needed is an efficient RPC 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