[Python-Dev] asyncore 2.1.1/2.2 incompatibility (original) (raw)

Zooko Zooko zooko@zooko.com
Sat, 23 Mar 2002 06:09:27 -0800

[add Cc: taral@taral.net, the author of an alternative to asyncore.py]

GvR wrote:

I think a way to tell asyncore to exit its loop on the next iteration is still a good idea, but as it's a feature, I don't think it should be added to any revision before 2.3.

When we used asyncore in Mojo Nation, we ended up writing a wrapper around it.
Here's the source:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyutil/pyutil/pyutilasync.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

When this happens, I think it's worth examining if some of the functionality of the wrapper deserve to be in the standard library. In particular, we added a way to tell asyncore to exit after the next select returns and is processed.

We also added a way to trigger the current select from a different thread so that our newly ready writer could get started. We also added a simple FIFO event queue for arbitrary functions to be invoked from the asyncore thread.

BTW, I intend to try an alternative to asyncore.py, written by taral@taral.net if I have time to experiment with it. This alternative uses an interface in which the higher-level code registers and unregisters, instead of the asyncore interface in which the lower level code polls the higher level asking "Now are you ready? Now are you ready?". This change will hopefully eliminate the last performance hotspot in my comms code as identified by profiling.

(It will also, I think, clear the way for an implementation of the async module which uses nice new async I/O like FreeBSD's kqueue for excellent performance.)

Regards,

Zooko

             zooko.com

Security and Distributed Systems Engineering