[nanomsg] Re: Polling
- From: Ondrej Kupka <ondra.cap@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 1 Jul 2013 22:06:55 +0200
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
Other related posts:
