[zeromq-dev] max_app_threads = 512
matt_weinstein at yahoo.com
Tue Jun 15 21:31:30 CEST 2010
On Jun 15, 2010, at 2:42 AM, Martin Sustrik wrote:
>>> 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
>>>> and an extra service thread.
>>> Mhm. Does it?
>> Good question
>>> My idea was to generate a guid when sending a request (see src/
>>> 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.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev