[zeromq-dev] Language binding guidelines

[gonzalo diethelm]

> > 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!

Yes, thank you for the concern. I am in Santiago, where the quake was
"only" between 7.5 and 8. Down south, about 400 Km away, where it
reached 8.5, things are pretty bad.

> 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!

I think I lean more to the former, for a single reason: in the latter,
you must expose your Context object (z). Also, see below (*).

> > 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!)

I don't know about finalize() not being called when process is shutting
down.

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

This is the main concern here, since a socket that lingers on will
definitely have visible effects.

> Definitely, the issue should be addressed in binding guidelines.

Probably best would be to have an explicit close() for Socket objects,
and a destroy() for Context objects. If we hide the context behind a
single ZMQ class (*), you could also make sure that when
Context.destroy() is called, you first call close() on all relevant
Socket objects.

-- 
Gonzalo Diethelm



----------------------------------------- 
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena. 
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje. 

"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law. 
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.