[Python-Dev] Adding Python-Native Threads

[Phillip J. Eby]

At 05:04 AM 6/26/2005 -0600, Adam Olsen wrote:
>On 6/26/05, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> > Have a look at stackless python. http://www.stackless.com/
>
>On 6/26/05, Florian Schulze <florian.proff.schulze at gmx.net> wrote:
> > Also look at greenlets, they are in the py lib http://codespeak.net/py
>
>While internally Stackless and Greenlets may (or may not) share a lot
>with my proposed python-native threads, they differ greatly in their
>intent and the resulting interface they expose.  Stackless and
>Greenlets are both tools for building an architecture that uses
>threads, while my python-native threads IS that resulting
>architecture.
>
>For example, with Greenlets you would use the .switch() method of a
>specific greenlet instance to switch to it, and with my python-native
>threads you would use the global idle() function which would decide
>for itself which thread to switch to.

See PEP 342 for a competing proposal, that includes a short (<50 lines) 
co-operative threading example.  It uses the 'yield' keyword instead of 
your '@' proposal, and already has a Sourceforge patch implementing it.

It does not propose a specific built-in idler or I/O handler, but such 
things could be added later.  In the short term, I think it's enough that 
Python be *able* to have such things (without using Stackless or 
Greenlets), and maybe include an example of a run loop.  I don't currently 
plan to push for a "standard" or "official" run loop implementation in 
Python 2.5, however, unless all the relevant stakeholders just happen to 
come to some kind of agreement that makes it happen.

Note that while having a universal run loop is a worthy goal, actually 
implementing one is hard.  The experts in this are definitely in the 
Twisted camp, as they have implemented run loops for numerous platforms to 
support compatibility w/various GUI frameworks' event loops.  To some 
extent, this means that the run loop needs to be an interface with multiple 
implementations, and I think that we would need a standard library 
implementation of PEP 246 in order to support it properly.

Anyway, my point is that even deciding on standards for a universal run 
loop is a fairly big project, one that possibly even deserves its own SIG 
to put together.  By contrast, the implementation of simulated threads and 
non-blocking function calls was a weekend project.