[zeromq-dev] Multithreaded ZeroMQ servers

[Pieter Hintjens]

If the work needed to handle a request is non-trivial, you have to
pass it to other threads that can work on it.

If you want examples, in C, look at the zproto project, and as a
worked example, study Malamute.

github.com/zeromq/zproto,
github.com/zeromq/malamute

-Pieter

On Mon, Jan 4, 2016 at 2:29 PM, Tom Quarendon
<tom.quarendon at teamwpc.co.uk> wrote:
> Ah, sorry. C++
>
> -----Original Message-----
> From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
> Sent: 04 January 2016 12:02
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: Re: [zeromq-dev] Multithreaded ZeroMQ servers
>
> Tom, what language are you working in?
>
> On Mon, Jan 4, 2016 at 12:48 PM, Tom Quarendon <tom.quarendon at teamwpc.co.uk> wrote:
>> I’m confused about writing multithreaded servers with ZeroMQ.
>>
>> I have read the ZeroMQ guide and there’s a section “Multithreading
>> with ZeroMQ” that has a description of how to write a multithreaded
>> Hello World server.
>>
>>
>>
>> However there appears to be an assumption that the “work” of each
>> request takes essentially the same amount of time. That is, the
>> requests are dealt out to the workers with a dealer socket, and so the
>> requests are just dealt out round robin aren’t they? So if one request
>> takes a long time, you could get into the situation that it ends up
>> with lots of requests queued up behind it for that worker, and all the
>> other workers are idle. That doesn’t seem right to me. But I may be misunderstanding how it works.
>>
>>
>>
>> In my mind what you want to be able to do is somehow have all of the
>> threads read from the same socket, or bind to the same external
>> endpoint, so that the each time a worker does a recv it gets the next
>> message that is in the input queue. Either that or you would appear to
>> need each worker to disconnect from the inproc socket each time it has
>> received a request to process so that it doesn’t get dealt any more,
>> and then reconnect when it has finished, but that feels like it might be undesirably inefficient.
>> Either that or I have to have a big lock and memory fence around the
>> input socket and just have each thread block waiting for the mutex and
>> then reading the next message.
>>
>>
>>
>> What I seem to want to end up doing is writing my own simple thread
>> safe in-process queue that I can just put the requests on to and have
>> all of the worker threads read from. However I’d like to use ZeroMQ if
>> I can, I just can’t work out how to.
>>
>>
>>
>> What am I missing?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev