python concurrency proposal
mwm at mired.org
Thu Jan 5 02:51:24 EST 2006
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
> 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 Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
More information about the Python-list