[zeromq-dev] Zero-copy message API

[Shonari Knibbs]

I don't think that the API needs to change at all. However, the
documentation is a little misleading:

"If provided, the deallocation function ffn shall be called once the
data buffer is no longer required by ØMQ, with the data and hint
arguments supplied to zmq_msg_init_data().".

This sentence indirectly says the following: if there is any clean-up
to be done once the data buffer is no longer required by ØMQ, then it
must be done in the deallocation function ffn (emphasis on the
_must_).

I think that fewer people will be tripped up by this function if it
explicitly stated that ffn is not optional if memory must be freed at
all (i.e. memory cannot be freed at some arbitrary point in the
future, instead, one must wait until the data buffer is no longer
required by ØMQ, which can only be guaranteed by use of ffn).

Shonari

On Sun, Apr 3, 2011 at 5:16 AM, Pieter Hintjens <ph at imatix.com> wrote:
> Hi Martin,
>
> One thing that seems to consistently trip up users is the zero-copy
> message API, and the way it's presented. That is, reading the docs,
> there's no hint that zmq_msg_init_data() is much harder to use
> properly than zmq_msg_init_size().
>
> For the 3.0 API, it could be neat to slice these apart and make it
> clearer that there is a simple way for 90% of apps, and a complex way
> for 10%.
>
> For example, zmq_msg_init() might take a size argument, and merge the
> functionality of zmq_msg_init_size(), and then we could rename
> init_data to zmq_msg_init_zerocopy().
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>