[zeromq-dev] Do Sockets free memory after..

[Wolfgang Richter]

If you're paranoid, and operating on a platform supporting Valgrind (or its
equivalent)
you could profile memory usage.

Valgrind is nice in that it will actually provide you the offending
"malloc" that was never
"free"d during program execution.

--
Wolf


On Thu, May 16, 2013 at 1:14 PM, Nishant Mittal <nmittal at rblt.com> wrote:

> thanks Pieter.. my application is just a zmq_proxy running in a thread..
> so I am not dealing with msgs in that application.. including the code for
> the device below..
>
> #include "TopicDevice.h"
>
> clTopicDevice::clTopicDevice(void *z_ctx, int front, int back) {
> int linger = 0;
>
> z_sub = zmq_socket (z_ctx, ZMQ_SUB);
>  z_pub = zmq_socket (z_ctx, ZMQ_PUB);
>
> int hwm = 10000;
> assert (zmq_setsockopt (z_sub, ZMQ_RCVHWM, &hwm, sizeof hwm) == 0);
>  assert (zmq_setsockopt (z_pub, ZMQ_SNDHWM, &hwm, sizeof hwm) == 0);
>
> assert (zmq_setsockopt (z_sub, ZMQ_LINGER, &linger, sizeof linger) == 0);
>  assert (zmq_setsockopt (z_pub, ZMQ_LINGER, &linger, sizeof linger) == 0);
>
> char temp[50];
>  sprintf(temp, "tcp://*:%d", front);
> assert (zmq_bind (z_sub, temp) == 0);
>
> sprintf(temp, "tcp://*:%d", back);
>  assert (zmq_bind (z_pub, temp) == 0);
>
> zmq_setsockopt (z_sub, ZMQ_SUBSCRIBE, "", 0);
> }
>
> void clTopicDevice::operator()() {
>
> zmq_proxy (z_sub, z_pub, NULL);
>
> }
>
>
>
>
> On Thu, May 16, 2013 at 1:06 PM, Pieter Hintjens <pieterh at gmail.com>wrote:
>
>> On May 16, 2013 4:07 PM, "Nishant Mittal" <nmittal at rblt.com> wrote:
>> >
>> > storing say a million msgs in its outgoing buffer and when the client
>> has finally caught up and consumed all msgs?
>> >
>> > I am seeing that the memory usage goes up as the client is slow or not
>> there but even after the client comes back and consumes all msgs.. the
>> memory stays where it was.. any comments?
>> >
>>
>> First, libzmq does not leak memory, that is certain. Second, your
>> application can leak memory if it does not e.g. close messages after
>> processing them. But then you would see a steady climb ending in
>> out-of-memory. What is plausible is that the shown memory usage is not
>> in fact allocated memory, but reserved memory.
>>
>> You can test this trivially.
>>
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
>
> --
> *Nishant Mittal*
> Director, Product Development
> *Rosenblatt Securities Inc*.
> 20 Broad Street
> New York, NY 10005
>
> Direct: 212-607-3159
> Mobile: 646-504-2629
>
> *Disclaimer:*
>
> *The information contained in this communication is not intended as an
> offer or solicitation for the purchase or sale of any securities, futures,
> options, or any other investment product. This communication is not
> research, and does not contain enough information on which to make an
> investment decision. The information herein has been obtained from various
> sources. We do not guarantee its accuracy. Any opinion offered herein
> reflects Rosenblatt Securities Inc. current judgment and may change without
> notice.          Member: NYSE, SIPC, FINRA*
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
Wolf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130516/69f1991f/attachment.htm>