[zeromq-dev] Language binding guidelines

[Martin Sustrik]

gonzalo diethelm wrote:
>>> 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 (*).

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.

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

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

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

Martin