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

[Pieter Hintjens]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100817/48475e84/attachment.htm>