For the CZMQ zloop reactor, at least, we're only rebuilding the pollset when there's a change. So that'd work nicely with epoll et al.
-Pieter On 11 Jun 2011 10:02, "Martin Sustrik" <[email protected]> wrote: > On 06/11/2011 12:04 AM, Marko Mikulicic wrote: > >> Just a comment: The performance gain with epoll et al. is tied to >> different API (only the file descriptors that are actually changed are >> passed to and from the API). Thus implementing old-style API like >> zmq_poll() on top of epoll doesn't make much sense. >> >> >> this API issue is exacerbated by the fact that the system call crosses >> the user/kernel boundary and large datastructures >> have to be copied to kernel space and back again. It could be possible >> to write an zmq_poll compatible implementation which detects changes in >> the zmq_poll_items >> arrays and applies corresponding epoll_ctl operations. The performance >> improvement, if any, would depend on how this trick plays well with the >> given invocation pattern of zmq_poll, >> but it is at least plausible to expect performance benefits from it. > > Sure. Feel free to implement it. I am a bit sceptical about possible > performance gain due to two factors: > > 1. To find out what the differences in the pollset are, zmq_poll() > implementation would have to scan and sort the pollset which has > complexity of O(n log n). > > 2. Users of the API would be tempted to re-create the pollset before > each call to zmq_poll() which would destroy any benefit which could be > possibly gained by using epoll-style mechanism underneath. > > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
