Should I close zeromq socket explicitly in python?

Question

In C/C++ like languages, closing zeromq socket explicitly is a must, which I understand. But in some higher level languages, such as php and python, which have garbage collection mechanism, do I need to close the sockets explicitly?

In php, there is no ZMQSocket::close() and in python, pyzmq's doc says socket.close() can be omitted since it will be closed automatically during garbage collection.

So my question is, do I need to manually close it or not?...

Perdurable

Answer 1

It is always correct to close any I/O resources when you are done with them. The garbage collector will close them off eventually. It may close it immediately once the last reference goes out of scope. It may close it as your program is exiting. While you wait for it to do so, the resource remains open taking up memory, consuming file pointers, and eating up your system resources in general. For a small, short lived program this may not be a big issue, but if your software is long living or establishes a lot of connections, this will come back to hurt you.

The answer is: it depends. If your system is reliant on the socket getting closed, then you are safer closing them explicitly. If you are fine with the socket getting closed at some indeterminate future time, you can save yourself a little bit of coding time and simplify your program a bit by just letting the garbage collector handle it.

Vertical

Answer 2

Things are changing - closing sockets not done automatically

Current documentation states, closing sockets (or calling Context.term() is not necessary as it is done automatically with garbage collection.

However, pyzmq changelog states, that since version 14.3.0 it is not true as changes in Python 3.4 does not allow to do such thing sensibly.

I have filed an issue Update docstrings about context.term() and socket.close() with regards to garbage collection for this.

Busty

If you read the response to the issue, ZMQ resources are properly cleaned up during normal execution. The issue is when the program stops unexpectedly, explicit closes are then required to clean up ZMQ resources or else you risk the next time you launch your program you won't even be able to connect to the same sockets as "their being used". You'll need to some how wrap your sockets and contexts to ensure during program failure you can properly remove your zmq resources. – Aeolian

Answer 3

You don't. You might close or delete things explicitly in Python when:

• Ordering becomes important, such as requiring the connection to be closed before you can proceed.
• Your references to the objects will persist for a long time, and the resource will no longer be required after some time. This might happen if you're storing them in lists or as member variables. You should explicitly close the resource, or remove references to it when you are done.

Generally speaking it's pedantic and premature to even think about such things in Python.

Delphinium

Interestingly I'm confronting the second senario you metioned above. In a daemon process I'll open a zmq socket and hold that reference until the process is stopped, e.g. receive SIGTERM. At that moment, should I explicitly invoke socket.close() or let gc do the job? – Perdurable

@Jerry: In that case just let the process terminate. The resources will be freed by the operating system. ZMQ will work out what's what. Additionally, the GC will usually attempt to clean up as much as it can in such circumstances. – Delphinium

Answer 4

It is considered good style to close ressources you use.

Normally, things are closed during garbage collection. But it is an implementation detail when __del__() is called. In CPython, you have reference counting and objects are discarded as soon as they are not used any longer. Other implementations as Jython etc. might work differently.

An implementation is allowed to postpone garbage collection or omit it altogether – it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable.

In 2.5 or 2.6, context managers were introduced in order to cope with exactly that kind of problems. Since then, it is considered goot style to work with files in this way:

with open(...) as f:
    # do stuff with file object f
# now it is automatically closed.

I don't know zeromq, but it might be that it has support for context managers as well.

I personally am sloppy if I work one-linerish via command line, but tend to be rather strict in complete programs. It is better to be explicit than implicit.

Notate