[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.
mattweinstein at gmail.com
Tue Aug 17 19:03:59 CEST 2010
Okay, I like the API bug approach.
How about two flavors of ZMQ_SUBS
ZMQ_SUBS_ALL - subscription socket, subscribed to "" ab initio
ZMQ_SUBS_NONE - subscription socket, no subscriptions ab initio
and deprecate ZMQ_SUBS by
#define ZMQ_SUBS ZMQ_SUBS_ALL
On Aug 17, 2010, at 12:22 PM, Pieter Hintjens wrote:
> On Tue, Aug 17, 2010 at 6:07 PM, Martin Lucina <mato at kotelna.sk>
>> The 0MQ library has no business asserting on user errors. Please do
>> introduce this behaviour.
> Mato, thanks for joining the discussion.
> IMHO the only part of this thread that really matters is whether or
> not there are valid use cases for blocking on a zombie SUB socket.
> The rest - whether we assert or return an error code - is
> implementation detail and I'm not going to argue it either way. I've
> no opinion EXCEPT that the current silent thread death is not
> acceptable, it is bad design, it hits every new user, and it requires
> explanation in the Guide that should not be necessary. I maintain
> that it's a design fault in the API and needs fixing one way or
> 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".
> 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?
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev