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" <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
