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

[Martin Lucina]

ph at imatix.com said:
> Please don't sidetrack this into a flame war over error codes vs.
> assertions.  That is besides the point.  ENOSUBS would be an fine
> option.  I've no preference for assertions except that we know from
> experience that fail-fast makes robust code when done correctly, and
> assertions are good place holders for "we need to do something about
> this when we've figured it out".

The point about assertions *is* important. Several people in this thread
have already asked, "Please, don't assert" yet you keep repeating "0MQ
should assert". I trust those other people are have not sidetracked the
thread into a flame war?

Y'know, it would be sufficient to just reply with "Point taken, thanks!" to
my points regarding assertions, especially since when we had the EFAULT vs.
assert() discussion you appeared to accept my identical arguments about why
go with EFAULT.

> Mato: could you re-read my analysis of the different use cases in this
> thread and tell me whether I'm wrong in claiming that none of the use
> cases already stated for zombie-sub-thread-death are valid?

I've re-read all of them several times and it would seem that no, they are
not valid. I'd still like some opinion from Martin Sustrik though, since he
implemented the current behaviour, whether by accident or by design.

Specifically, the concrete case where a thread invokes a *blocking*
zmq_recv () call on a ZMQ_SUB socket with no filters installed is invalid
since the zmq_recv () call will never complete.

However, there is a related problem also mentioned in this thread, namely
the conflict of zmq_recv () vs.  zmq_poll () semantics. It's obvious that
zmq_poll () should not return an error if such a socket is included in the
pollset.

However, going by your "It is our job to prevent people from shooting
themselves in the foot" line, what would you have zmq_poll () do if the
socket is the *only* socket in the pollset?

-mato