[Python-Dev] Adding Python-Native Threads
Phillip J. Eby
pje at telecommunity.com
Sun Jun 26 17:03:36 CEST 2005
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.
More information about the Python-Dev
mailing list