The nn_poll() API is a convenience API intended to make it easier to build
event loops with multiple nanomsg sockets. However, it lacks support for
working with native file descriptor objects, so you can only use it with
nanomsg sockets. Furthermore, the functionality it provides is available
via the NN_SNDFD and NN_RCVFD socket options (which let you obtain file
descriptors suitable for use with poll(), select(), epoll(), etc., and
which therefore you can use in more general event loops including native
file descriptors etc.)
I’d like to remove the nn_poll() API, if nobody is using it. It would be
timely to do this now, before 1.0. However, I only want to do this if
there are no extant users of nn_poll() who are not able to quickly switch
to using the socket options.
So, please let me know asap if you would be impacted if the nn_poll() API
were to vanish in 1.0.
(The rationale for removing this API is minimizing the support burden, and
shrinking libnanomsg to elide code that is of limited or no practical use.)
- Garrett
PS: I hope to have a different, and superior, notification mechanism
involving callbacks that the application can register for in the future.
Its unlikely that this will make 1.0, but I’m thinking to do this in the
near time frame after 1.0 is released. Unlike the current notification file
descriptors, this will be much more efficient, so that the system call
overhead of notification pipes can be eliminated for applications which do
not specifically demand it with the NN_RCVFD and NN_SNDFD socket options.
I expect that this will have a tangible performance benefit for a great
number of nanomsg applications.
