[zeromq-dev] Language binding guidelines

gonzalo diethelm gdiethelm at dcv.cl
Mon Mar 1 18:51:18 CET 2010


> >> 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 (*).
> 
> By more straightforward I've meant that you have a single namespace
> (it's really a namespace, it's never instantiated!) that everyting is
> placed into: constants, context, socket, poller etc.
> 
> In former option the things are a bit confused. There's a namespace -
> but, interestingly, it can (and must) be instantiated and serves as a
> context for sockets. Thus, identifier ZMQ actually refers to two
> distinct things - namespace of the library and context the sockets are
> instantiated in.

You are right. Although I am not sure about the consequences of mixing
the namespace and the instantiated context; probably I have been
programming in Java / C++ for too long...

> While in Java the problem is made less visible by having "org.zmq"
> package (kind of namespace) and no support for namespaces (ZMQ has to
be
> a class even though it's actually a namespace), in other languages
(say
> Ruby) the confusion is pretty clear...

I don't know enough Ruby to vouch for this, but I take your word.

> > This is the main concern here, since a socket that lingers on will
> > definitely have visible effects.
> 
> What about adding "close" function to the socket and "term" function
to
> the context?

Yes, we agree on this.

> >> 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.
> 
> The plan here is to use the option to close the context before sockets
> are closes to notify all the threads in the application about
shutdown.
> 
> The idea is that once you terminate the context, all the blocking
calls
> on sockets exit with ESHUTDOWN (or similar) allowing you to do cleanup
> and terminate the application decently.
> 
> While it may seem a bit strange, the semantics is pretty useful for
> multithread application termination. Without it you would have to open
> an inproc connection from main thread to every worker thread. Each
> worker thread would then have to poll on both it's "working" socket
and
> the inproc socket, the latter just to get the termination message.
This
> mechanism is unneeded annoyance to implement and is at the same time
> detrimental to performance.

I had forgotten 0MQ probably keeps an internal list of sockets
associated with its context; it certainly makes sense to have all
outstanding socket operations fail in a graceful manner. I like this
approach.

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




More information about the zeromq-dev mailing list