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
