[zeromq-dev] kqueue & epoll based zmq_poll

Marko Mikulicic marko.mikulicic at isti.cnr.it
Sat Jun 11 00:04:08 CEST 2011

On 10 June 2011 17:33, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi folks,
> >>> For zmq_poll(), only select/poll based polling is available.
> >>
> >> Are there any plans to implement the advanced polling mechanisms
> >> into zmq_poll where available? Not that I suffer from any
> >> performance problem in zmq_poll right now, just asking ;)
> >
> > I'm not aware of any plans by the core devs to add this. If you feel
> > like taking a poke at it, I'm certain there are a few people on the
> > list (and irc) who could give you advice and answer questions.
> 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
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.

> To get the real performance gain we would need something like
> zmq_epoll() or zmq_kqueue().

Yes, and on the other hand, a zmq_epoll-like api can more easily be emulated
on top of a underlying poll() system call,
so it could be chosen as the preferred official API with easy degradation on
systems which don't support epoll.

The core difference is that poll() specifies the full list of events at each
poll() invocation, while epoll and kqueue maintains this list in the kernel
and offers api to alter it. So a epoll/kqueue/whatever agnostic API can be
constructed, like libevent etc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110611/39147493/attachment.htm>

More information about the zeromq-dev mailing list