Pythonic concurrency (was: Erlang (was Re: Good introduction to
Aahz Maruch
aahz at panix.com
Tue Jan 2 13:27:16 EST 2001
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!
More information about the Python-list
mailing list