[zeromq-dev] Regarding java binding of 0MQ.

SM swapnil at hardcodr.com
Sun Dec 12 23:26:41 CET 2010


I think Scott's complain regarding supporting deregisteration of
socket in poller was very relevant as I myself faced this issue. I
tried to create similar "remove" interface for my own use. Refer patch
for the same.

---
SM

On Thu, Nov 25, 2010 at 4:04 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
> Regarding point #1, you are right: the flags were assigned to a long
> variable, which was received in the C glue code as a jlong, which was
> finally cast to an int when being passed into zmq_send() and zmq_recv(). I
> changed them into int / jint and got rid of the cast.
>
>
>
> Regarding point #3, I don’t think we should introduce any changes, as per
> the discussion on the mailing list.
>
>
>
> Regarding point #2, could you propose a concrete interface for what you
> mention?
>
>
>
> I have also implemented the timeout handling in the poll() methods:
>
>
>
> poll() will behave depending on whether setTimeout() has been called: if
> yes, it will use that timeout value; if not, it will block indefinitely.
>
> poll(timeout) will always honor whatever timeout value it is explicitly
> receiving.
>
> [gs]etTimeOut() methods have been deprecated.
>
>
>
> Let me know of any comments or suggestions.
>
>
>
>
>
> Gonzalo Diethelm
>
>
>
> ________________________________
>
> From: zeromq-dev-bounces at lists.zeromq.org
> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Scott Asher
> Sent: Wednesday, 24 November, 2010 14:30
> To: zeromq-dev at lists.zeromq.org
> Subject: Re: [zeromq-dev] Regarding java binding of 0MQ.
>
>
>
> You should just break backwards compatibility.  The binding should match the
> C/C++ behavior.
>
>
>
> BTW, I DID complain about the constants being made private and moved to
> Poller, but no one listened and it wasn't a big deal.
>
>
>
> Also, another couple of issues while we're on the Java bindings:
>
>
>
> 1) (minor) The send/receive flags (e.g. ZMQ.NOBLOCK) are defined as ints,
> but the functions expect longs.
>
> 2) (more annoying) Because the Poller class makes all of its underlying data
> structures (e.g. the Socket array) private, the only way to even CHANGE what
> events a socket is listening for is to recreate the Poller object and add
> sockets to it again.  It would be nice to either expose the underlying
> structures so we can manipulate stuff ourselves or write a set of functions
> (e.g. deregister or an overloaded version of register which reregisters)
> that do everything for us.
>
>
>
> 3) (related to 2) You can register a socket twice because your register
> functions have no existence check.  I don't know what the behavior is here
> (haven't tested it).  On the Java side I basically have to do a lot of
> recreating pollers that I don't have to do on the C++ side.
>
>
>
> Scott
>
> ________________________________
>
> 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. 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.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.poller.deregister
Type: application/octet-stream
Size: 2897 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101213/3d114356/attachment.obj>


More information about the zeromq-dev mailing list