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

[Matt Weinstein]

Hmmm...

Are you asserting based on (asynchronous) conditions in an unrelated  
component of a system (vs. e.g. asserting in recv() because of a  
malformed protocol)?  If so, how would you describe the assertion from  
a correctness proof standpoint?

IMO you might consider an error return, but asserting here is fragile.

IMO waiting forever is consistent (no other recv fails because it  
doesn't understand why you're doing something).  The failure is easily  
detected and remedied.

However, I'll make you a deal: add a setsockopt like  
ZMQ_SUBSCRIBE_EMPTY_OK to remove the error behavior.  Then I can  
happily use it if I know what I'm doing.

This kind of "error guard" behavior could be used elsewhere, but it  
really doesn't belong at this layer....

Best,
Matt


On Aug 17, 2010, at 10:12 AM, Pieter Hintjens wrote:

> This use case is easy to distinguish. Plus I doubt you would code  
> that as a blocking receive in any case, it makes no sense. You'd use  
> two sockets, and poll.
>
> Sent from my Android mobile phone.
>
> 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.
> >
> > Should recv return ESILLY at that point? What's the thread going to
> > do while waiting for ETERM? Should it run its exit code out of
> > sequence with the other threads that were doing other work?
> >
> > Then there's always the fact that threads can be killed or signaled,
> > and its possible that a signal could bounce the thread somewhere to
> > subscribe. Heck, it could be inside someone's custom kernel.
> >
> > I think making this change helps in one very simple case (newbie)
> > while creating a hostile and less expressive environment.
> >
> > -1
> >
> >
> > I'd suggest the newbie wrappers instead.
> >
> >
> >
> > On Aug 17, 2010, at 9:26 AM, Pieter Hintjens wrote:
> >
> >> On Tue, Aug 17, 2010 at 3:14 PM, Matt Weinstein
> >> <matt_weinstein at yahoo.com> wrote:
> >>
> >>> You're right, and I can't find it.
> >>> Basically, you could be waiting for ETERM, but I forget the other
> >>> case.
> >>
> >> I think it was a subscriber that dynamically adds/remove filters  
> and
> >> at some point ends up with no filters. But that's a broken use case
> >> because if code ever ends in that state it won't exit the recv().
> >>
> >> Martin also mentioned waiting for ETERM but it seems nasty to use a
> >> SUB socket for that and especially to allow this trap to exist  
> simply
> >> to support that use case.
> >>
> >> My suggestion: if code calls zmq_recv() without NOBLOCK on a SUB
> >> socket with no filters, 0MQ asserts.
> >>
> >> As a secondary suggestion, the null/block case turns into  
> "subscribe
> >> to EVERYTHING" which is what 100% of people want when they naively
> >> write code and omit the filter.
> >>
> >> Yesterday I spent 30 minutes wondering why my subscriber wasn't
> >> working. Facepalm... but it just should not require additional  
> effort
> >> to make the simplest possible case work.
> >>
> >> -
> >> Pieter Hintjens
> >> iMatix - www.imatix.com
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100817/9c2060cc/attachment.htm>