Ah, but this is probably not thread safe, sorry for the distraction, use the PUSH/PULL pair. :)
-Michel On Mon, Aug 13, 2012 at 11:59 AM, Michel Pelletier <[email protected]> wrote: > Using a waker socket is a great approach like MinRK said, FWIW it's > not necessary to create a push and a pull socket, a single DEALER > socket can connect to itself. Here's a tweak of MinRK's diff: > > https://gist.github.com/3343232 > > Lately I've been on a tirade of deprecating PUSH/PULL in my code in > favor of DEALER in all cases, this looks like another nice case. > > -Michel > > On Mon, Aug 13, 2012 at 11:49 AM, MinRK <[email protected]> wrote: >> >> On Mon, Aug 13, 2012 at 11:05 AM, Arthur O'Dwyer <[email protected]> wrote: >>> >>> Hi all, >>> >>> I'm trying to use ZMQ in what I guess (surprisingly to me) is an >>> unconventional way. The salient points of our protocol are: >>> >>> - The connection has only two ends: exactly one client and exactly one >>> server. >>> >>> - In fact, the labels "client" and "server" are mostly unnecessary; >>> requests can originate on either side. Sometimes the client asks the >>> server something, and sometimes the server asks the client something. >>> >>> - Answers to questions don't come right away (requests and replies are >>> not nicely nested). If the client has two things to ask the server, it >>> can do both requests at once, and the server can spawn two worker >>> threads to compute the answers in parallel. >>> >>> I believe the architecture we need is a work queue on each side: when >>> a client thread asks a question, it puts a request packet P_a and a >>> timeout value T_a into the "outbox" and then waits on a condition >>> variable associated with that transaction-ID. There's a master ZMQ >>> thread with three responsibilies: >>> >>> - Whenever the outbox is non-empty, pull a message from it and >>> send it over the wire. >>> - Whenever a request comes in over the wire, spawn a new worker >>> thread to handle that request. >>> - Whenever a reply comes in over the wire, match its >>> transaction-ID to our list of waiting workers and notify the worker >>> who's waiting for this particular reply. >>> - T_a seconds after the request P_a goes out over the wire, if the >>> reply hasn't come yet, notify the waiting worker that the reply has >>> timed out. >>> >>> Also, we'd like to have a "heartbeat" in both directions. But I >>> believe that can easily be handled as a special kind of worker thread >>> on each side, whose only job is to send a request every N seconds and >>> complain if the reply times out. >>> >>> This feels like a really simple and common architecture, and I also >>> believe it would work out of the box if ZMQ supported calling >>> zmq_poll() from multiple threads (because then we wouldn't even need >>> the master thread; all of this queuing ickiness would happen inside >>> ZMQ itself). But for the life of me I can't figure out how to get ZMQ >>> to wait on "something is incoming over the wire *or* >>> some-other-event", without just polling every millisecond inside a >>> loop. >>> >>> Suppose Thread A is waiting inside zmq_poll(); is there any way for >>> Thread B to say "Hey! Wake up right now! I need to send a message!"? >> >> >> You can do this by creating a waker socket just for this purpose, and always >> including it in the poll set: >> >> https://gist.github.com/3343165 >> >> -MinRK >> >> >>> >>> >>> Thanks much, >>> -Arthur >>> _______________________________________________ >>> 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
