[nanomsg] Re: Polling

  • From: Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Mon, 1 Jul 2013 16:12:37 -0400

Hi Ondra

If there was a way to do this in Java, Channels would certainly be
involved. The problem is that there doesn't seem to be an official,
documented way of tying a Channel with an (external) file descriptor; I
have seen a couple of low-level tricks, but they all involve JNI and
low-level implementation details (like using private fields), which is not
very reassuring...

Best regards.

On Mon, Jul 1, 2013 at 4:06 PM, Ondrej Kupka <ondra.cap@xxxxxxxxx> wrote:

> Hi Gonzalo,
>
> Haven't been doing Java for quite some time, but
> http://docs.oracle.com/javase/7/docs/api/java/nio/channels/package-summary.html
>  looks
> promising, although I don't know the exact solution. It's written there
> that a channel is equivalent to a file descriptor, so I guess you need to
> get the right channel somewhere and then you can use it. The question is
> then if you can get it at all, maybe you will have to implement the
> interface yourself… But I am in no way a Java expert :-)
>
> Cheers,
> Ondra Kupka
>
> On Jul 1, 2013, at 9:25 PM, Gonzalo Diethelm wrote:
>
> There doesn't seem to be an explicit polling mechanism in nanomsg. There
> is also this assertion in http://250bpm.com/blog:21:
>
> *"Polling mechanism, given that it is a glue between disparate types of
> subsystems (file systems, networking stack, etc.) must be defined by the
> platform rather than by any individual subsystem (such as nanomsg). Thus,
> binding developer should try to integrate nanomsg into the native polling
> mechanism. File descriptors retrieved from the socket using NN_SNDFD and
> NN_RCVFD socket options can be used for this purpose. If the language
> doesn't provide a native polling mechanism or if it doesn't provide a way
> to plug arbitrary file descriptors into the native polling mechanism, then
> the binding should do the second best thing and implement a polling
> function/object itself."
> *
>
> It seems Java would fall under the category of not providing a sensible
> way to integrate these nanomsg-provided file descriptors into a native
> polling mechanism; at least I have not found a clean way to do that. I
> would like to ask three questions on this list:
>
> 1. Can any Java experts chime in on my conclusions? Is there a clean way
> to integrate these file descriptors returned by nanomsg into a Java native
> demultiplexing mechanism?
>
> 2. Assuming there is no way to do that, what would be the proper way to
> follow the recommendation to "implement a polling function/object itself"
> in Java? The only way I see is to provide it in native JNI (C) code, which
> leads me to my following question.
>
> 3. If this happens not only to Java, but also in other languages, would it
> not be a better idea to have nanomsg provide this polling function/object,
> and have the binding from these "blighted" languages call that
> implementation?
>
> --
> Gonzalo Diethelm
> gonzalo.diethelm@xxxxxxxxx
>
>
>


-- 
Gonzalo Diethelm
gonzalo.diethelm@xxxxxxxxx

Other related posts: