[nanomsg] Polling
- From: Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 1 Jul 2013 15:25:45 -0400
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:
