this just needs to be decided.
i propose that you should need to zmq_close, and furthermore,
that you need to zmq_close a msg you have zmq_msg_init()ed
in the case you do not do a zmq_recv on it.
my reasoning is thus:
1) despite your claim below, the manual actually says "initialise ... msg to
represent an empty massage".
2) no where is there any defn of an empty message.
3) however, intuitively, one feels that an empty message is pretty much teh
same as one of size 0,
so that these should be equivalent:
zmq_msg_init(&msg);
zmq_msg_init_size(&msg, 0);
(this is reminiscent of the debates about whether malloc(0) allocates
memory.
it certainly might; the point is that malloc(n) returns enough space to
store n bytes
and not necessarily exactly n bytes.) similarly, zmq_msg_init_size says
it allocates
enough resources to store a message of n bytes; that implies to me that
there
may be allocation involved even if n is 0.
4) it certainly is plausible (even likely), that zmq_msg_init_size(&msg, 0) will
allocate storage, and so you need the sequence
zmq_msg_init_size(&msg, 0);
zmq_msg_close(&msg);
in order to prevent memory leaks.
5) by combining 3) and 4), it seems you need to do
zmq_msg_init(&msg, 0);
zmq_msg_close(&msg);
in order to prevent memory leaks.
6) and by extension, you would need to do
zmq_msg_move(&dmsg, &msg);
zmq_msg_close(&msg);
zmq_msg_close(&dmsg);
in order to prevent memory leaks.
On Jul 31, 2012, at 10:40 PM, Pieter Hintjens wrote:
> On Wed, Aug 1, 2012 at 10:10 AM, Andrew Hume <[email protected]> wrote:
>
>> what is exactly the status of src after calling this function?
>> the manual page says it becomes an empty message, whatever that is.
>> do i need to call zmq_msg_close(src)?
>> is it the same as calling zmq_msg_init(src)?
>
> zmq_msg_init says it creates an empty message, i.e. a message of size
> zero, so that seems consistent.
>
> It's unclear whether you need to call zmq_msg_close on an empty
> message. The reference manual doesn't discuss this. One would assume
> it's not needed, but that may be dependent on how messages are
> implemented.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
------------------
Andrew Hume (best -> Telework) +1 623-551-2845
[email protected] (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
