threads and sleep?

[Grant Edwards]

On 2005-07-05, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

> Don't think you can do that with Python... The Python runtime
> interpreter itself is running on a single processor.

I don't see how that can be.  Under Linux at least, the Python
threading module uses "real" OS threads, so there are multiple
instances of the interpreter, right?  Generally all but one of
them will be blocked on the GIL, but there are still multiple
interpreter threads (which can be on multiple different CPUs).

Or is the Python interpreter actually doing the context
switches itself?

> The second thing is the infamous "global interpreter lock"
> (pull up the Python documentation and do a search for that
> phrase).

The GIL is the issue.

> Basically, even if the threads could be assigned to
> processors,

Can somebody explani why they can't?

> this lock means only one thread can be performing Python
> operations at a time -- a C-language number crunching module
> /could/ release the lock, then do its number crunching in
> parallel, reacquiring the lock when it finishes so it can
> return its result(s) as Python objects.

True.  Python can execute C code in parallel, but not Python
code.

> Tou might get the results you want by not using threads,
> instead spawning off completely new Python invocations
> assigned to other processors.

That should work, but managing the inter-process communication
and syncronization is a pain.

-- 
Grant Edwards                   grante             Yow!  If Robert Di Niro
                                  at               assassinates Walter Slezak,
                               visi.com            will Jodie Foster marry
                                                   Bonzo??