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

[Pieter Hintjens]

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?

-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.