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

[Matt Weinstein]

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