Re: [libvirt] [PATCH 1/2] Java bindings for domain events
Now that I'm actually wading around in the Java java.nio.channels Select
swamp (getting this implemented), this is looking like it has exactly
the same portability problems as my original code.
This approach requires providing our own Selector (and SelectorProvider,
corresponding handle/timeout Channels, and SelectionKeys), with our own
native implementation of something that can provide select/poll
functionality (because there's no way to get that functionality via Java
for arbitrary unix fds; can't even construct java FileDescriptors from
them in native code because FileDescriptors are declared final). And we
also must implement Selector.wakeup() that can interrupt a select
operation in another thread (requiring something like the pipe() in my
original code - since the select operation will itself be in native
code, so can't rely on Java thread interruption).
So in the end this looks more like a java.nio.channels.Selector-style
interface wrapped around a libvirt EventImpl (which might as well be the
one copied from qemud). Certainly that exports a more standard
interface for integration with a foreign event loop, but at this point,
that looks like the only benefit. For now, I'll continue, assuming the
more standard interface is worth the extra code. The Java side of this
is basically done, with "only" the JNI code to write.
Just wanted to set expectations ...
Dave
On Wed, 2008-11-19 at 08:34 +0100, Daniel Veillard wrote:
On Tue, Nov 18, 2008 at 01:12:42PM -0500, David Lively wrote:
> On Tue, 2008-11-18 at 16:51 +0000, Daniel P. Berrange wrote:
> > On Tue, Nov 18, 2008 at 11:06:10AM -0500, David Lively wrote:
> > > The attached patch (against libvirt-java) implements Java bindings for
> > > libvirt domain events. This version provides a libvirt EventImpl
> > > running in its own Java Thread, and provides per-Connect synchronization
> > > that makes using the bindings thread-safe. (Note the Domain, Network,
> > > StoragePool, and StorageVol methods also synchronize on their Connect
> > > object, as required by libvirt. I have similar changes for
> > > NodeDevice.java that need to be made when that code is checked in.)
> >
> > I don't particularly like the event loop code because it is adding a huge
> > pile of non-portable JNI code that won't work on Windows, which lacks
> > pipe() and poll(). Java already provides a portable pure Java API for
> > building a poll() like event loop in form of NIO.
> >
> > http://www.xhaus.com/alan/python/jynio/select.html
>
> Yeah, Daniel V and I had briefly considered this, and rejected it on the
> basis of "it's complicated" and (more importantly) some negative
> feedback I hear from our Java folks on the java.nio Select mechanism.
>
> But I agree the java.nio Select mechanism should greatly decrease the
> amount of JNI code in the Java EventImpl. I need to look over the docs
> again, but I think it's "just" a matter of implementing a
> SelectableChannel on top of a fd. (That JNI code will presumably be
> very different in Win32 and Unix, but it should be a relatively small
> amount of JNI code in comparison to my current impl.)
>
> So I'll look over the java.nio Select documentation and start thinking
> about a more portable approach ... (and also talk more with our Java
> folks about their Select gripes).
I guess it's better to invest a bit more time and come up with a
solution relying as much as possible on Java threading, I/O and
synchronization. After all we should capitalize as much as possible
on the portability work done in the Java engine, and limit the
C part of the bindings to the strict minimum JNI (as much as possible).
On one hand we want the bindings to be the easiest possible to use
and avoid threading limitation imposed to the client code, on the other
hand limit the C part on those issue, of course that means growing
the java side of the bindings, but it really should be easier to
maintain and port than equivalent C code, even if NIO is not the
nicest Java API :-\
Daniel