[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.
ph at imatix.com
Tue Aug 17 16:12:27 CEST 2010
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
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.
> 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
>> 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
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev