[zeromq-dev] zmq_poll

[Martin Sustrik]

Hi all,

I read the whole thread and here are my comments:

1. The goal is not to use single 0MQ socket from multiple threads at the 
same time, it is to allow for migrating 0MQ socket to another 
application thread.

2. The functionality is needed to integrate 0MQ with Erlang (or any 
other language that allows for migrating its native threads among OS 
threads). It cannot be done as a layer on top of 0MQ. It's a feature 
that is implemented in the very core of 0MQ. However, if it turns out 
that performance impact is noticeable, it can be switched on/off at 
compile time.

3. The only performance-related change would be replacing one socketpair 
per application thread (current state of affairs) with one socketpair 
per 0MQ socket.

4. Given that single 0MQ socket is capable of handling thousands of 
underlying connections, one application thread is expected to use at 
most 3-4 0MQ sockets. If it uses more of them, the design is probably 
broken.

5. Given that zmq_poll works only for sockets owned by the same thread 
we should expect the pollset to have at most 3-4 elements (+ native file 
descriptors which don't count).

6. The actual performance penalty would be that zmq_poll would 
internally have to poll on 4 fds instead of just 1. Also, if there 
happen to commands for multiple sockets available they would have to be 
read from mulitple fds rather than doing it in a one go.

7. The impact of the above would -- IMHO -- be minimal. I am not 100% 
sure though.

8. There's another issue, namely that number of socketpairs used would 
grow (say 3x if you are using 3 sockets in each application thread). 
Depending of the implementation of socketpair, this can inrease memory 
usage and consequently number of cache misses.

In overall, I would say the functionality should be implemented and 
tested for performance. It may turn out that the performance impact is 
so small that it can't even be measured.

Martin