multiprocessing module (PEP 371)

[pataphor]

In article <877a5774-d3cc-49d3-bb64-5cab8505a419
@m3g2000hsc.googlegroups.com>, sturlamolden at yahoo.no 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.