[zeromq-dev] Language binding guidelines

Martin Sustrik sustrik at 250bpm.com
Mon Mar 1 16:32:27 CET 2010

Hi Gonzalo,

> A few comments. Sorry for not sending a patch; I am in Chile, where
> we were recently hit by a major earthquake, so my access to the repo
> is flaky at best.

I've read about it in paper. I hope you and your family are OK!

> Change "binging" to ""binding" in this paragraph: "As these constants
> are the main extensibility mechanism for ØMQ, developer of the
> binging should make it as easy as possible to add new constants to
> the set."


> On OO languages, I think Brian's idea about putting everything inside
> the global ZMQ class makes sense. If we carry this idea to the
> extreme, it would mean that the Context object might very well be
> invisible to the user:
> class ZMQ { private Context context;
> public ZMQ() {...}
> public Socket makeSocket(...) { /* use context here */ } }
> You might have several of these ZMQ objects initialized at the same
> time (each hiding a Context object). The nice thing about this
> approach is that the user only deals with Socket objects (through the
> ZMQ class).

Right. We should decide which one is nicer:

z = new ZMQ ();
s = z.makeSocket (ZMQ::PUB);

z = new ZMQ::Context ();
s = new ZMQ::Socket (z, ZMQ::PUB);

My preference is for the latter. Two reasons:

1. It's the current way it is. No need to change the API.
2. It's more obvious what's going on. The former example is a bit cryptic.

However, feel free to outvote me!

> Question: Java does not have proper destructors; there are no
> assurances as to when an object that is not used anymore will be
> chosen for destruction. This means there is no way to explicitly
> invoke the corresponding calls to zmq_term() (for Context) and
> zmq_close() (for Socket). If this might be a problem, perhaps we
> should expose these calls through an explicit destroy() / close()
> method in the binding. What do you think? What is the case in other
> languages? This is sort of covered in the proposed policy, but it is
> not explicitly mentioned in the context of languages lacking
> destructors.

Good spot!

There's finalize but AFAIK it's not guaranteed to be called immediately 
after there are no references to the object. Moreover, it doesn't have 
to be called when the process is shutting down. (Correct me if I am wrong!)

This means that 0MQ sockets may linger on even after you've closed them, 
using memory, CPU power, maintaining network connections etc.

I suspect the same problem may pop up in other garbage collected 
languages. Anyone any experience here?

Definitely, the issue should be addressed in binding guidelines.


More information about the zeromq-dev mailing list