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@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@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@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev