[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zeromq-dev
Subject:    Re: [zeromq-dev] memory preallocation for realtime use cases
From:       Uli_Köhler <ulikoehler.dev () googlemail ! com>
Date:       2013-05-19 20:33:19
Message-ID: CA+vDtgJn1cAE1yHvccpgbYyGo+T2V3Vz4Df2TDqS_xc0vfAVwQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi Michel,​

What transport method are you using? If you're not using inproc, I suppose
the IO threads will allocate memory on their own - besides that, the
lockfree pipes (see ypipe.c) will probably also allocate some memory.
Please check the source code to be absolutely sure, if these factors matter
in your use case.

Maybe the REUSE flag can partially solve your problem, as far as I
understand it, it prevents the message (zmq_msg_t) itself from being free'd
once sent.

Best regards,
Uli

[Attachment #5 (text/html)]

<div dir="ltr">Hi Michel,​<div><br></div><div style>What transport method are you \
using? If you&#39;re not using inproc, I suppose the IO threads will allocate memory \
on their own - besides that, the lockfree pipes (see ypipe.c) will probably also \
allocate some memory. Please check the source code to be absolutely sure, if these \
factors matter in your use case.</div> <div style><br></div><div style>Maybe the \
REUSE flag can partially solve your problem, as far as I understand it, it prevents \
the message (zmq_msg_t) itself from being free&#39;d once sent.</div><div \
style><br></div><div style> Best regards,</div><div style>Uli</div></div>



_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[prev in list] [next in list] [prev in thread] [next in thread]