[zeromq-dev] Can I make sure that contexts are freed and handles released in a fast loop?
kubaraczkowski at gmail.com
Thu Feb 23 18:01:13 CET 2012
Thank you for your answer.
Indeed, I was expecting context termination to wait until all resources are
returned, but this somehow does not happen.
Setting linger time was also my first thought, but it seems not to help.
I will create a simple test case tomorrow and report back. Should you have
any more suggestions, please don't hesitate to write :)
On Thu, Feb 23, 2012 at 4:37 PM, Ian Barber <ian.barber at gmail.com> wrote:
> On Thu, Feb 23, 2012 at 6:27 AM, Kuba <kubaraczkowski at gmail.com> wrote:
>> The function creates a context and a socket, connects to the server,
>> sends a message, receives a message, closes the socket, terminates the
>> context .... and starts over again.
>> This works very well and very fast, though the actual socket handles (or
>> file handles) never get released, which causes the program to crash after
>> some (thousands) iterations.
>> I know that your answer to this problem will probably be: "keep the
>> context and the socket open as long as possible", but not doing that is
>> exactly the point of my client.
>> Therefore, the question: is it possible to make sure, within a program,
>> that all contexts/sockets/files/handles are properly closed, so that they
>> can safely be relaunched ?
> If you properly close sockets and term the context it will free up any
> resources - whether or not it will try and deliver remaining messages, or
> wait for how long, is controlled by the ZMQ_LINGER sockopt (this may be the
> source of your problems). It may take the kernel some time to make bound
> ports available again if you are reopening within a quick loop - there's
> nothing much that can be done at that level afaik. If you're seeing
> resource not being released at all it sounds like a bug, and I would try to
> create a minimal test case.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev