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: > NB: > > 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: > Matt, > > 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: > > Repeat: > - 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 > filters. > > 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 > relevant) > * If you made the classic programming error (which is relevant and > which I'd like to catch). > > Are there flaws in this reasoning? > I'm exiting. > -Pieter > > >> On Aug 17, 2010 3:49 PM, "Matt Weinstein" >> <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
