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

[Aahz Maruch]

In article <881A12DF74ECCB7D.31A676568924AC5F.3D8A4DED140164F7 at lp.airnews.net>,
Cameron Laird <claird at starbase.neosoft.com> wrote:
>
>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 not necessarily correct for standard Python threads (which are
built on OS-level threads).  I know that it's true for NumPy, but I also
know that it's not true for mxODBC.  That is, it depends on whether the
extension is written to release Python's Global Interpreter Lock (GIL);
mxODBC releases the GIL and NumPy does not.  If you want to find out
whether a given extension releases the GIL, look in the source code for
the macros Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

It *is* generically true for microthreads, though.
-- 
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Happy second year of the new millennium!