In article <877a5774-d3cc-49d3-bb64-5cab8505a419 @m3g2000hsc.googlegroups.com>, [EMAIL PROTECTED] says...
> I don't see pyprocessing as a drop-in replacement for the threading > module. Multi-threading and multi-processing code tend to be > different, unless something like mutable objects in shared memory is > used as well (cf. Python Shared Objects). If this limitation can > educate Python programmers to use queues instead of locks and mutable > objects, even multi-threaded Python programs may actually benefit. > Some API differences between threading and multiprocessing do not > matter. Programmers should not consider processes as a drop-in > replacement for threads. This is probably not very central to the main intention of your post, but I see a terminology problem coming up here. It is possible for python objects to share a reference to some other object. This has nothing to do with threads or processes, although it can be used as a *mechanism* for threads and processes to share data. Another mechanism would be some copying and synchronization scheme, which is what posh seems to do. Or maybe not, I haven't used posh yet, I just read some docs (and I already hate the "if process.fork():" idiom, what are they trying to do, reintroduce c-style assignment and swiching?). By the way I haven't done much thread and process programming, but the things I *have* done often combine threads and processes, like starting a console oriented program in a background process, redirecting the IO and communicate with it using an event loop in a thread. I gets more complicated when a gui thread is also involved, for example when retrofitting a gui interface to an existing terminal based chess or go playing program. P. -- http://mail.python.org/mailman/listinfo/python-list
