I think what I want is essentially what is described in " A Load Balancing Message Broker". It's basically what I have written, though I did it slightly differently by having two 0mq queues, rather than having the "worker_queue" array. Basic point is the same, that the workers do a "request/reply" conversation with the main thread to get work, and the main thread has to service both the front end queue and the back end queue.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pieter Hintjens Sent: 04 January 2016 15:05 To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] Multithreaded ZeroMQ servers 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 <[email protected]> wrote: > Ah, sorry. C++ > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Pieter > Hintjens > Sent: 04 January 2016 12:02 > To: ZeroMQ development list <[email protected]> > 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 <[email protected]> > 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
