[zeromq-dev] preparing bindings for 2.1 release?

[Martin Sustrik]

Gonzalo,

> I have added these two as options in the Java binding, via the
> Socket.getFD() and Socket.getEvents() methods.

I am not sure whether Java can make any use of native file descriptors. 
Can it? If not, there's no point in exposing FD to the user.

An option would be to wrap the retrieved FD into native Java descriptor 
(if such a thing exists) but that would probably be pretty non-trivial 
to implement.

>> ZMQ_TYPE returns type of the socket (ZMQ_REQ, ZMQ_PUB etc.)
>
> This was already supported in the Java binding, via the Socket.getType()
> method.

See my comment in the issue tracker.

>> 1. 0MQ sockets can be migrated between threads. This is important for
>> the bindings.

> Does this have any impact in the binding implementation? I would say no.

Presumably no. Rather it can fix some mysterious crashes that may have 
occured when socket was migrated from application thread to GC thread. I 
am not aware of reports of such crashes though. Interesting...

>> 2. The socket shutdown semantics have changed. Namely, when socket is
>> closed using zmq_close it doesn't mean that queued outgoing messages
> are
>> dropped immediately. Socket is closed straight away, but the messages
>> will be sent anyway. Consequently, zmq_term's semantics are changed so
>> that it blocks and prevents application to exit until all the
> remaining
>> messages are sent.
>
> Does this have any impact in the binding implementation? I would say no.

One impact I can think of is that zmq_term can now block. Given that 
it's called from GC thread in Java... well, I am not sure what happens 
if GC thread is blocked, but it doesn't sounds scary.

Possible solution would be to add term method to the context so that 
user would be able to terminate the conxtext explicitly and thus block 
in application thread rather than in GC thread.

Martin