[zeromq-dev] Deadlock between REQ/REP sockets?

[Dana Leonard]

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:

> Dana,
>
> > 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?
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100601/4360e3a2/attachment.htm>