[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.
matt_weinstein at yahoo.com
Tue Aug 17 17:02:12 CEST 2010
BTW, how will inter-thread socket portability affect this?
Will the grab_the_socket() operator cause the recv to exit?
Will a second thread be able to add subscribes for you?
I found my original comment:
> A multi-socket blocking poll() could legitimately include a ZMQ_SUBS
> with no subscriptions.
> A socket without subscriptions might be waiting for a zmq_term()
So why should poll() behave differently on the socket than recv()?
You're interpreting program correctness.
On Aug 17, 2010, at 10:40 AM, Pieter Hintjens wrote:
> To clarify why this use case does not apply:
> - A subscriber listens to a SUB socket
> - It also gets commands via a second socket
> - It applies those commands to the SUB socket as filters
> Its logic will be:
> - poll for activity on either socket
> - if cmd socket, subscribe/unsubscribe filter
> - if sub socket, process incoming data
> If there are no filters, it cannot get activity on the sub socket.
> Therefore it will never block on recv() on the sub socket with no
> The only cases I can see where you'd end up blocking on a dead SUB
> socket are:
> * If you combined commands with updates on one socket (bad design, we
> don't need to support it)
> * If you mysteriously decided to stop using poll and switch to
> blocking recv() just when the last filter is gone (pathological, not
> * If you made the classic programming error (which is relevant and
> which I'd like to catch).
> Are there flaws in this reasoning?
>> On Aug 17, 2010 3:49 PM, "Matt Weinstein"
>> <matt_weinstein at yahoo.com> wrote:
>>> Can't assert, it's a legitimate case, imagine a socket that receives
>>> command sequences, and finally receives its last unsubscribe just
>>> before ETERM, e.g.
>>> [S] CMD
>>> [S] ABC
>>> [S] DEF
>>> ... weeks later...
>>> [U] ABC
>>> [U] DEF
>>> [U] CMD
>>> Should I bring down the whole platform (on the remote side)?
>>> Should the controller have sent [U] CMD? Probably not, but that's
>>> life, it shouldn't cause a calamity.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev