[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.
matt_weinstein at yahoo.com
Tue Aug 17 17:02:07 CEST 2010
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:
> 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....
> 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
>> > 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
>> > 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
>> >> at some point ends up with no filters. But that's a broken use
>> >> 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
>> >> 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
>> >> 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
>> >> 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
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev