[zeromq-dev] zmq_poll

[Chuck Remes]

On May 21, 2010, at 3:46 PM, Martin Sustrik wrote:

> Serge Aleynikov wrote:
>> Sounds exciting.  Does it mean you are putting it on your development 
>> plate?  ;-)
>> 
>> Not sure how much support you need to justify this feature, but you have 
>> my vote!  This will make architecture of 0MQ more naturally blending 
>> with the philosophy of Erlang, and hence the Erlang 0MQ driver will be 
>> more straight forward to implement without bending backwards.
> 
> Give me the weekend to think about it.
> 
> 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?

I'm not really in favor of anything that makes zmq_poll slower. All of the code I am writing with 0mq utilizes non-blocking sockets and polling so I can process things in an asynch fashion.

My whole goal is to process every socket in a given context within a single thread. If I need more CPU, I spin up a new context in a separate thread and do all of my processing asynchronously. As of now I'm not sharing data between contexts but I clearly could using ipc/inproc transports.

I hate paying the penalty for memory barriers / mutexes / semaphores / condition variables, etc.

My 2 cents.

cr