[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