python concurrency proposal

[Mike Meyer]

Corey Coughlin <corey.coughlin at comcast.net> writes:
> Mike Meyer wrote:
>> Calls to methods of a separate object are non-blocking. The calls are
>> queued, and executed later. Reading an attribute from a separate
>> object is a blocking action.  Calling a method with a separate object
>> as an argument causes the call to block until the separate arguments
>> are all locked. There are rules - enforceable by the compiler - about
>> what you can do with separate objects that prevent a lot of the things
>> that cause headaches when doing concurrent programming.
> Undoubtedly enforced by contracts, Eiffel is nice that way.

Actually, no. "separate" is a property of a variable, and certain
things you can do with normal variables you can't do with separate
variables. The semantics of contracts do enter into things,
though. When you pass a separate variable to a function, the function
blocks until the separate variable is available, and all the
preconditions that mention it are true. This gives you gaurded
semaphores.

> Yeah, the dynamic nature of python makes a straight translation of
> SCOOP pretty problematic.  But it's good stuff to consider,
> definitely some great ideas in there.  I'm not really sure I want a
> solution that gets as complicated as SCOOP, but it may not be
> something I can avoid.  Ah well, some thinking to do.  But just out
> of curiosity, would you support a PEP with some language additions
> to support and simplify concurrency?

I'm certainly interested in seeing such a thing done to
Python. Whether I'd support a specific PEP would depend on the PEP.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.