[zeromq-dev] max_app_threads = 512
sustrik at 250bpm.com
Tue Jun 15 08:42:44 CEST 2010
>> 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.
>>> 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/
>> 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.
More information about the zeromq-dev