[zeromq-dev] Deadlock between REQ/REP sockets?
dleonar at gmail.com
Tue Jun 1 14:29:15 CEST 2010
Correct. For an update, the attachment process seems to be working much
better with the P2P socket thread disabled (pthread_create() commented out).
Perhaps the IPC message handler was not getting CPU time to process the
message somehow and was only swapped in once the client quit. I am now
finding seg faults coming from zmq_engine.cpp, line 119 according to GDB.
Currently investigating this.
On Tue, Jun 1, 2010 at 8:06 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> > Ok, so the server in our case is really more of a messaging hub. Clients
> > attach to it so that they can talk to one another without having to
> > create a nasty web of sockets to one another. We plan on having IPC
> > communication as well as TCP to remote clients. So the PUB/SUB model
> > doesn't really work for our case. The heart of the problem really lies
> > in the initial attachment calls using the REP/REQ model.
> So you want to have:
> 1. central hub to dispatch reuqest and replies
> 2. clients that connect to the hub, send requests and receiver replies.
> 3. services that connect to the hub, receive requests dispatched by the
> hub and send replies back to the hub. Hub then routes the replies to
> original requesters.
> Is that your use case?
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev