[zeromq-dev] clarification regarding zero copy

KIU Shueng Chuan nixchuan at gmail.com
Thu May 9 06:22:04 CEST 2013


Setting no blocking flag means that when the send hwm is reached, your
messages simply get dropped with an error code (which you are not checking
in your code snippet). I believe the default hwm is 1000, so you would have
hit it in your loop of 10000.

In your callback function, you could set a flag/semaphore/event. In your
loop, you would then wait on your synchronization object before proceeding
to reassign your string.

This is probably not what you want since the same  synchronized effect
could be achieved with non zero copy.

You could also allocate a fresh string on the heap on each loop iteration
and delete it in your callback function.
On 9 May, 2013 11:11 AM, "Erdos" <covariantmonkey at gmail.com> wrote:

> Thanks for the reply. The docs indeed confirms that the free function is
> called when zmq is done with the buffer.
>
> However, I'm more interested in what happens right after the "send" call.
> As my loop is set up, the send function (with NO_BLOCK) will return
> immediately and I will go back to the top of the loop where the buffer is
> getting re-assigned. What happens in between that short time window? How do
> *I* know that zmq is not quite done with the buffer and maybe I should wait
> before re-assigning the buffer.
>
> Obviously, an option is to remove the NO_BLOCK (s.t. send call blocks till
> its done) but an expert opinion would put my mind at ease.
>
> Cheers,
> Asif
>
>
> On Wed, May 8, 2013 at 9:17 PM, KIU Shueng Chuan <nixchuan at gmail.com>wrote:
>
>> Your callback function "respawn" is called when zero mq is done with the
>> buffer.
>> On 9 May, 2013 8:50 AM, "Erdos" <covariantmonkey at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have a short bit of code to send data over a push socket via the
>>> zero-copy mechanism:
>>>
>>> static void respawn(void* data, void* hint){};
>>> int main ()
>>> {
>>>   zmq::context_t context (1);
>>>   zmq::socket_t socket (context, ZMQ_PUSH);
>>>   socket.connect ("tcp://localhost:5555");
>>>
>>>   string payload = "";
>>>   for (int request_nbr = 0; request_nbr != 10000; request_nbr++) {
>>>     payload = "boo";
>>>     zmq::message_t request ((void *)payload.data(), payload.size(),
>>> respawn); //L1
>>>     socket.send (request, ZMQ_NOBLOCK); //L2
>>>   }
>>>
>>>   return 0;
>>> }
>>>
>>>
>>> Its not entirely clear to me if I can safely assume that the buffer
>>> 'payload' is available to me immediately following the 'send' operation
>>> (L2).
>>>
>>> Does the 'send' internally copy the contents of payload on to something?
>>> You can see why if for some odd reason the contents are not immediately
>>> dealt with (i.e. zmq is still waiting to do something with payload buffer),
>>> then assigning new values to payload at the top of the loop is just wrong.
>>>
>>> The code block above runs just fine but I would like to be sure-- are
>>> there any mechanism for zmq to signal that it has finished dealing with
>>> payload buffer and okay for me to re-assign it?
>>>
>>> Many thanks
>>> Asif
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130509/6aadd612/attachment.htm>


More information about the zeromq-dev mailing list