[zeromq-dev] zmq_poll

[Serge Aleynikov]

On 5/21/2010 4:46 PM, Martin Sustrik wrote:
>
> The change would simplify the architecture and allow sockets to be
> migrated between threads (given the proper memory barriers).
>
> On the other hand it would have performance impact. Specifically,
> zmq_poll would be somehow slower as it would have to deal with more fds
> (one per 0MQ socket). Also, memory consumption would be higher given
> larger number of open fds.
 >
 > Thoughts?

First of all, I think you would only see this performance impact when 
you deal with a very large number of sockets in your application (over 
100s?), which is likely not the most typical use case.  Secondly, even 
if you have that many sockets, you'll likely still have some 
application-level code that iterates through them when using zmq_poll to 
determine which ones have in/out events.  No?

In any case, it's always more reliable to do some proof of concept 
testing rather than doing this comparative guess work regarding 
potential performance impact.  Possibly simplification of architecture 
maybe a good incentive on its own.  It's likely that many 0mq users 
(including myself) are concerned with performance, yet the need for this 
feature is truly not because someone wants to be able to run more 
threads using blocking socket interface, but rather because it would 
allow to decouple 0MQ sockets from the threading model and give a 
developer a chance to use the threading model most suitable for solving 
his/her problem.

BTW, if you are going to spend some time thinking about this, perhaps it 
would be helpful to take a look at specification of socket API of SCTP 
protocol in a way how the concept of a connection is separate from an 
association between endpoints (talking about one-to-many sockets).

Serge