[Python-Dev] Synchronous and Asynchronous servers in the standard library

Josiah Carlson jcarlson at uci.edu
Sun Nov 7 22:53:56 CET 2004


"Phillip J. Eby" <pje at telecommunity.com> wrote:
> 
> I believe that this may be an unrealistic goal, even though I have done 
> something rather similar myself.  There is a myriad assortment of policy 
> issues you'll have to swim upstream past, just to get to the mechanism 
> issues.  For example, Twisted assumes its reactor is an interpreter-global, 
> maybe even process-global event loop, whereas asyncore and peak.events 
> allow multiple event loops.
> 
> I've dabbled in integrating Twisted and peak.events, such that code written 
> for peak.events can run with or without Twisted, and such that an 
> asynchronous server can be run synchronously.  So, it's certainly possible 
> to do something like what you're describing, but I'm not sure it's worth 
> the effort versus someone simply installing PEAK and/or Twisted.

Since most people are saying that this would be ugly (at least in the
realm of Twisted), I'll take back the offer.


> Now, if the Python standard library included a lightweight task switching 
> facility akin to Armin's greenlets, it might be more practical to include 
> asynchronous communications facilities in the stdlib.  Essentially, one 
> could implement a set of communication primitives that task-switched to a 
> global scheduler, or one could supply the scheduler as part of the calls, 
> or provide the primitives as methods of a scheduler, etc.  This would 
> bypass most of the architectural policy issues.

Re: greenlets

If someone were ambitious, one could write an implementation of
greenlets using standard threads for platforms without an optimized
greenlets implementation.

 - Josiah



More information about the Python-Dev mailing list