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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
