[zeromq-dev] max_app_threads = 512

Matt Weinstein matt_weinstein at yahoo.com
Tue Jun 15 21:31:30 CEST 2010

On Jun 15, 2010, at 2:42 AM, Martin Sustrik wrote:

> Matt,
>>> I'm working on infrastructure for migrating sockets at the moment in
>>> case you are interested in it.
>> I suppose it would eliminate the service thread and queue in exchange
>> for locking running contexts against a mutex and full memory barrier
>> to switch owners.
>> == many threads == queue -- one thread -- outbound socket
> Yes. In theory you can use it that way. Obviously the performance will
> be poor and no fair-queueing will be done.

Yes, you're probably right.

How about lockless queues (pipes) and round-robin scheduling, similar  
to what you're doing.  I can just wake up my service thread with a  
single condition_variable and do the scan and forward.

Are there other performance implications / does that sound workable?   
Or am I missing something?

>>>> I haven't built
>>>> the GUID matching and distribution code yet, which may have a
>>>> performance impact because it needs thread safe containers, a  
>>>> queue,
>>>> and an extra service thread.
>>> Mhm. Does it?
>> Good question
>>> My idea was to generate a guid when sending a request (see src/
>>> uuid.hpp)
>>> and append it to the message. Then to chop of the GUID from reply
>>> and if
>>> doesn't match the expected GUID drop the message.
>> The service thread and queue provide a solution to the many-to-one
>> problem for sockets.  I may sleep the contexts against a condition
>> variable, we'll see..
>> I do hitchhike on 0MQ's uuid XREQ protocol.
> Ok.
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list