On Sat, Jun 11, 2011 at 1:59 PM, Martin Sustrik <[email protected]> wrote:
> Ok. I should have not mentioned the second caveat. The real point is that > epoll is meant to reduce complexity of polling from O(n) -- where n is the > size of pollset -- to O(1). If we use epoll to implement zmq_poll(), we get > complexity of O(n log n) which is actually worse than O(n) that you get > using poll or select. Yes, if you use epoll you'd want a new API, not zmq_poll. Like I said, if you use a reactor on top of zmq_poll, it should be transparent to applications. In any case, using zmq_poll for anything complex is a pain, it gets rapidly messy to keep track of timers and events. Do we have figures for the cost of zmq_poll? I'm kind of sceptical of any optimization that's not based on solid numbers. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
