[rfc] developer documentation on user interaction

[Russel Winder]

John,

On Fri, 2009-09-25 at 10:03 -0500, John Arbash Meinel wrote:
[ . . . ]
> So interestingly, python2.6 provides a 'multiprocessing' module in the
> standard lib, which is roughly equivalent to 'threading'.

Now we are on to concurrency/parallelism territory, so I am home
turf :-)

multiprocessing certainly is in the standard library, it used to be the
add on package processing (and that is how you get it for 2.5 and
earlier.

processing/multiprocessing was designed to be a drop in replacement for
threading but using processes rather than threads.  This is to get round
the GIL problem and allow a single Python program to work on parallel
systems in parallel.  It spawns multiple PVMs and uses message passing
(via pickling) to ship messages from one process to another.

The important point is not that it is a mechanism for handling
subprocesses, it is a tool for structuring Python code so that it
harnesses any parallelism available -- this shift of mindset is in many
ways very subtle and a revolution.

Many people think processing/multiprocessing should not have tried to
stay with the threading API structure.  There are a number of other
packages and sub-systems looking at harnessing parallelism, Python CSP,
Kamaelia, etc., etc.

> In that you can say "multiprocessing.Process(python_func, *args)" and it
> will spawn a subprocess that calls python_func with appropriate
> arguments. It basically uses cPickle to marshal and unmarshal python
> objects across the barrier.

True but it is much better if you ignore all that implementation detail
and get on with structuring the application as a data parallel one or a
process and message passing one.  As soon as you think marshal/unmarshal
you are too low-level. 

> I *don't* know how well it works with interactivity, or getting
> progressive updates (can python_func be a generator rather than a plain
> function? etc)
> 
> I would certainly consider switching the windows installers to python2.6
>  for 2.1.0b1 and if it goes well, we could do the same for 2.0.1 or
> whatever version comes out at a reasonable time.
> 
> I realize qbzr may want to keep backwards compatibility with python 2.4,
> which is what bzrlib itself works to support. But it is an idea.
> 
> 
> John
> =:->

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel at russel.org.uk
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder at ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090925/39c03778/attachment-0002.pgp