Pythonic concurrency (was: Erlang (was Re: Good introduction to

[Cameron Laird]

In article <G6GqJw.1oD at world.std.com>, Will Ware <wware at world.std.com> wrote:
>> Cameron Laird wrote:
>> > Is this true:  microthreads block on system calls (I/O
>> > operations, most notoriously) and on invocations of
>> > externally-coded extensions?
>
>Just van Rossum (just at letterror.com) wrote:
>> They do.
>
>Yup, microthreads treat Python opcodes as atomic, including system I/O
>calls and calls to C extensions. This is because Stackless Python is a
>mechanism for tweaking the execution order of the Python virtual machine,
>which steps thru Python opcodes. My earlier assertion was sloppy. My bad.
			.
			.
			.
As you know, Will, this is a not-particularly-widely-understood
region of computing, and I think it can stand a bit more expo-
sure.  Your good (and you're good) for making it clear.

Naive readers might wonder, why does it matter?  Here's an
example:  you need a win32api calculation, maybe something com-
puted by an (external) Excel process.  You ask for the result.
Ten seconds later, it hasn't returned.  At this point, you might
want to tell the end-user, "We're still grinding; don't give up",
OR start an alternate calculation likely to yield an approximation
quickly OR signal Excel to give up OR ...  With a conventional
Python architecture, though, you can't.  Even if you put the Excel
invocation in its own thread or microthread, no other Python
thread can regain control until Excel gives it back.

That's a big issue for some people, while others go decades with-
out encountering it.

Correct, Just and Will?
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html