I know it is a bit old, but would Python Object Sharing (POSH) http://poshmodule.sourceforge.net help you? Also, if you think you like the current state-of-the-art threading model, you might not after reading this:
http://tinyurl.com/qvcbr This goes to an article on http://www.computer.org with a long URL entitled "The Problem with Threads." After some initial surprise when I learned about it, I'm now okay with a GIL or even single threaded python (with async I/O if necessary). In my opinion threaded programs with one big shared data space (like CPython's) are fundamentally untestable and unverifiable, and the GIL was the best solution to reduce risk in that area. I am happy the GIL exists because it forces me to come up designs for programs and systems that are easier to write, more predictable both in terms of correctness and performance, and easier to maintain and scale. I think there would be significant backlash in the Python development community the first time an intermittent race condition or a deadlock occurs in the CPython interpretor after years of relying on it as a predictable, reliable platform. I'm also happy the GIL exists because it forces alternative ideas like Twisted and stackless to be developed and tried. If you have shared data that really benefits from synchronized access and updates, write an extension, release the GIL at the appropriate places, and do whatever you want in a C data structure. I've done this when necessary and think it is the best of both worlds. I guess I'm assuming this will still be possible in Python 3000 (I haven't been on the list that long, sorry). There has to be a better concurrency model than threads. Let's design for the future with useful packages that implement the best ideas of today for scaling well without threads. Ross _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
