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

Gregory P. Smith greg at electricrain.com
Tue Nov 9 00:10:42 CET 2004


On Mon, Nov 08, 2004 at 06:50:25AM +0100, "Martin v. L?wis" wrote:
> Andrew Bennetts wrote:
> >One such list is here:
> >    http://mail.zope.org/pipermail/zope3-dev/2002-October/003235.html
> 
> I fail to see any of these as problematic:
> 
> 1. invokes readable/writable in each round, thereby not preserving
>    state; presumably ok for select and poll, but bad (wasting
>    performance for kqueue).
>    I can't see this as a problem: asyncore does use select/poll,
>    not kqueue. In doing so, it first processes all ready file
>    descriptors before going to the next round, so in the next
>    round, it needs to check all dispatchers again.
>    There seems to be an implicit assertion that anything that uses
>    select/poll must be evil, and the only true API is kqueue.
>    I can't claim to understand the rationale for introducing
>    kqueue in the first place, but if it is to improve performance,
>    then I expect that any performance gained in kqueue over
>    select goes away by using Python (e.g. adding an indirection
>    in dispatching is probably more expensive than what kqueue
>    would have saved).

The complaint about the readable and writable methods is partially the
overhead of doing a method call for each file descriptor every time
thru the loop.  Its inefficient.  Itamar mentions that both select()
and poll() effectively maintain a reusable data structure that could
be maintained directly by the file descriptor event handlers rather
than expensively querying them all each time thru the loop.

In any given iteration thru the loop its typical for only a small
fraction of the file desciptors to change readable/writable state so
why not have them manage their flag directly.  (analogy: a push rather
than a pull of the readable/writable state to the event loop)

-g



More information about the Python-Dev mailing list