[Python-Dev] asyncore 2.1.1/2.2 incompatibility

[Zooko]

[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
---