[zeromq-dev] [jzmq] xreq/xrep sockets and thread safety
matt_weinstein at yahoo.com
Thu Aug 12 19:23:30 CEST 2010
The DEVICE service thread is not designed for processing "stuff".
One design: two threads on your side -- one which is an async request
thread (unless you get some form of signal) and an async response
[ clients ] [ REQ ] == [ XREP ] == [ DEVICE ] + 2 streams:
==> [ ZMQ_PUSH ] == [ ZMQ_PULL ] [ ASYNC_REQUESTER ]
<== [ ZMQ_PULL ] == [ ZMQ_PUSH ] [ ASYNC_HANDLER ]
I'm presuming the async API can efficiently share state between the
two ASYNC_* threads.
What are you actually making requests to...?
Use zmq_reactor to build DEVICE (use the poll_items branch).
On Aug 12, 2010, at 1:09 PM, Alexey Ermakov wrote:
> Hi everyone,
> I'm trying to figure out how to deal with the thread safety
> restriction of 0MQ sockets. As I understand, they are bound to a
> thread, which means that I write/read to the same socket from
> multiple threads (which is possible with Java Posix socket
> wrappers). I'm trying to figure out how to implement a rather simple
> task and I can't think of a decent solution.
> My application is a Scala-based server that has an XREP socket,
> processes the requests, and replies back. The catch is that request
> processing is implemented by forwarding a request to another service
> using an asynchronous API. How am I supposed to send the replies
> back, if the XREP socket is bound to the thread that is basically
> blocked on "while (true) socket.recv()"? I suppose I could do a 50ms
> poll on the socket and then process the replies (fetching them from
> a LinkedBlockedQueue or something), but that would be inefficient,
> because requests/replies happen much less frequently. Another
> solution would be replacing all inter-thread communication with 0MQ
> sockets and doing a poll() on these sockets in the request handler,
> but that doesn't sound very nice.
> Is there an easier solution I'm overlooking?
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev