[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.

[Matt Weinstein]

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"  
>> <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
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev