[zeromq-dev] recvmsg deprecated

[Andrew Hume]

the difference is that unless you decide in advance that there is a maximum packet,
the byte oriented APIs (which mimic write(2) and read(2)) don't work on read for
network packets. unless, of course, you added a
	int32 zmq_next_msg_size(void *sock)
which returns -1 if no packet awaits and its size if there is one. still, it seems
easier just to use msg_t's.

	how do people use zmq_recv now? do they assume a packet size limit?
and how can they tell if they lost data?

On May 15, 2013, at 6:08 AM, Pieter Hintjens wrote:

> On Wed, May 15, 2013 at 11:26 AM, Andrew Hume <andrew at research.att.com> wrote:
> 
>> what is teh strength of zmq_recvmsg being "deprecated"?
>> should i worry that in fact it is going away?
>> or is it just a poor choice of words?
> 
> It won't disappear from the API for a long time but it's marked as
> deprecated to encourage bindings and apps to use the zmq_msg_xxx set
> of functions.
> 
> Deprecating this and other functions (zmt_init, zmq_term, zmq_recvmsg)
> was part of making the API more consistent. There's no functional
> difference. There's also no hurry to remove the old functions; I'd
> expect these to disappear only in a 4.x release or so.
> 
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


-----------------------
Andrew Hume
623-551-2845 (VO and best)
973-236-2014 (NJ)
andrew at research.att.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130515/bc61ff72/attachment.htm>