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

[Martin Lucina]

Pieter,

ph at imatix.com said:
> 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.

-1

The 0MQ library has no business asserting on user errors. Please do not
introduce this behaviour.

Pieter, we went through this with your complaint about the API calls not
being resistant to NULL values and this is why I requested the addition of
EFAULT.

There are several arguments against these kinds of assertions, the most
obvious of which are:

 - An assertion is not a documentable return value from a 0MQ call
 - Asserting makes the naive user think the problem is in 0MQ and not in
   their code

Now, there are likely cases in the current code where you do get assertions
in 0MQ if the user does something silly (half-sent multipart messages
spring to mind), all such cases should be considered bugs and fixed
eventually to either return an error code or otherwise deal with the
situation without asserting.

> 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.

-0.5

This creates situations where you could connect to a huge feed and start
getting all the data, not sure if this is better than the current
situation, in any case it's a big semantic change in the API.

I'd be inclined to go with the solution of returning an ENOSUBS or similar
when no filters are set, but not before I see some more discussion of
whether or not the zmq_recv() on a SUB socket with no filters is a valid
use case.

-mato