[libvirt] [PATCH 1/2] Java bindings for domain events

[David Lively]

On Wed, 2008-11-19 at 10:48 +0000, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2008 at 08:34:41AM +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).

Agreed -- BUT if we don't make libvirt allow asynchronous EventImpl
callbacks (the second patch in this series (plus requiring pthreads,
which sounds like a Big Deal for WIN32)), we'll have to stop the
EventImpl callbacks from happening:
 (a) at the same time *ANY* connection (in the same process) is in use
     (because EventImpl callbacks aren't necessarily associated with any
     particular connection, though they might be)
 (b) at the same time another EventImpl callback is happening

The patch already synchronizes operations using virConnect objects with
each other.  To avoid making illegal EventImpl callbacks from Java for
the current libvirt, I have to lock every Connect object known to Java
and hold off creating new connections (via open & friends) around an
EventImpl callback.  This sounds rather appalling to me, but it's
starting to sound like the only practical route in the short term
(unless it turns out we can rely on pthreads in WIN32 ...).

Alternatively, I could just use one global lock for everything, but that
essentially single-threads all libvirt operations, which seems *really*
undesirable.

> >   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 :-\

Yeah, I suspect so.  I'm starting to implement this path ...

> Also, while I remember any event loop implementation in Java should
> be an optional add-on class, not a mandatory part of the Java libvirt
> bindings. Applications may well already have an event loop they wish
> to use - for example a java desktop application will have an event
> loop provided  by GTK or QT. So all that would be require is a Java
> binding to the libvirt-glib module, so you cn register libvirt with
> Glib from Java.

Gotcha.  I've just installed glib-java-devel, so I'll make sure this
easily integrates with a glib event loop as exposed in glib-java.

Dave