On Thu, 2017-08-31 at 15:30 +0100, Luca Boccassi wrote: > On Thu, 2017-08-31 at 16:16 +0200, Stephan Opfer wrote: > > Hi all, > > > > I am trying to use zmq_msg_init_data in order to have the zero-copy > > advantage. > > > > Now it is required, that I either pass a function, that can > > deallocate the data after zmq sent it, or I pass NULL in order to > > keep the ownership. > > > > In the latter case: How do I know that zmq has done his work and I > > can deallocate the data? > > Locally, the only sure way is when the socket has been closed and the > context has been terminated. But that of course is not ideal in a > long- > lived application. > > If your protocol implements ACKS (request-reply pattern for example), > then it's implicit that when receiving a response the original > request > was received. > > > Another idea was to pass a lambda function (with a capture) to zmq, > > in order to make zmq send a signal by calling the lambda function. > > The problem is, that it is not allowed to pass lambda functions > > with > > captures as function pointers and without captures, I have no clue > > how zmq could pass the signal. > > > > Maybe somebody of you now already have an idea? > > > > The general idea is: > > > > My robotic application keeps some sensor values for a while and > > sends > > some of the values to other robots via zmq. Therefore I don't want > > the data to be copied and I don't want zmq to deallocate it. I want > > my own application to deallocate it, if it is not needed anymore > > and > > zmq did send everything. > > > > Greetings, > > > > Stephan > > A solution could be to make a shallow-copy of the message via > zmq_msg_copy. This will not copy the data buffer, only the message > metadata and references, which are a few bytes at most. The data > buffer > ownership is refcounted. > > Then when your application is done with the data, you can call > zmq_msg_close on the _copy_, which will decrease the refcount. > > So the last one to be finished with the data, whether it's your > application or the library, will deallocate it.
Another, more complicated way, would be to implement a mark&sweep garbage collector of sorts: instead of freeing the buffer, the callback you register with zmq_msg_init_data would mark the buffer as done (in a thread safe way!). Then your application's garbage collector can sweep it. It's certainly more complicated than taking a shallow copy in C/C++ but in some languages it might be easier. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
