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

[Matt Weinstein]

An alternative to the setsockopt proposal: another RECV flag  
ZMQ_RECVERR that forces error returns vs. asserts.

On Aug 17, 2010, at 10:48 AM, Matt Weinstein wrote:

> 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
>
> _______________________________________________
> 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/51d77af2/attachment.htm>