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

[Pieter Hintjens]

Yes, the dynamically configured subscriber is a very nice use case. You're
certainly right that my suggestion would break that. I'll sleep on it.
Thanks.

- Pieter

Sent from my Android mobile phone.

On Aug 18, 2010 1:00 AM, "Alexey Ermakov" <zee at technocore.ru> wrote:
> On Wed, Aug 18, 2010 at 2:35 AM, Pieter Hintjens <ph at imatix.com> wrote:
>> Anyhow, this is in no way a formal proposal, it's just an idea for
>> discussion since people seem always to trip up on this aspect of SUB
>> sockets.
>>
>> There's no question of breaking existing code, throwing any babies out
>> with the water, etc. except in a major version and after really
>> careful thought.
>
> I'm sorry if my previous message looked like an overreaction. I
> understand that this is not a final spec and was just trying to add my
> two cents.
>
>> For market data use cases nothing would change except some API
terminology.
>> In fact the proposition only changes one use case (no subscriptions).
>> What it does is turn the language around to fit common experience. People
used to market data and messaging frameworks will have no trouble either
way, they have been experts at this for years.
>
> What I've been trying to argue in my previous messages is that even
> changing one use case (poll()/recv() on a ZMQ_SUB socket with no
> subscriptions) from its current behavior to “receive everything” would
> make these sockets impossible to use for stuff like market data.
> Consider this rather typical use case: I create a socket for getting
> market data and an inproc API socket for handling subscriptions.
> With the current behavior, this socket works nicely: if I call poll()
> on the two sockets, I'll only get subscription commands at first. Once
> I set up some subscriptions, I'll start receiving data. If I remove
> all my subscriptions, I'll once again stop receiving any sort of
> market data. If publisher-based prefix matching gets done, it all
> transparently becomes very efficient network-wise.
> If you change the default to “receive from all”, suddenly everything
> becomes very ugly. Yes, developers that blindly call recv() on a
> freshly made SUB socket will get their data, but the use case I
> described above becomes impossible to implement without all sorts of
> dirty hacks (delay SUB socket connection/binding until the first
> subscription, close and recreate the socket instead of calling the
> last unsubscribe, as there's currently no disconnect/unbind call).
>
> Also, this proposed API change doesn't look very logical to me
> semantically. The socket's called ZMQ_SUB for a reason — it deals with
> subscriptions. Returning no data if I haven't subscribed to anything
> seems perfectly fine, they're called “subscriptions” for a reason.
> Yes, there's a potential case where it locks a thread forever, but
> that shouldn't be solved by transparently subscribing to everything.
> Perhaps it would be better to make recv() return EAGAIN after a
> predefined timeout (to prevent high CPU usage)?
>
> I liked the filtering idea (especially the negative filters), but they
> don't make sense as a primary means of “configuring” a
> _subscription_-based socket. As an additional filter they would be
> very nice to have, but as the only “recommended” (as in not
> deprecated) configuration option they only make sense for a PULL
> socket.
> _______________________________________________
> 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/20100818/e04fe3ca/attachment.htm>