[zeromq-dev] zmq_poll

[Brian Granger]

On Fri, May 21, 2010 at 3:52 PM, Chuck Remes <cremes.devlist at mac.com> wrote:
> 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.

+1

>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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com