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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4