[libvirt] [PATCH] Java bindings for domain events

[David Lively]

The attached patch (against libvirt-java) contains Java bindings for the
new domain event code.  It works (see EventTest.java), but there's a
certain amount of hokiness regarding the EventImpl stuff that I'd like
to discuss.

Unlike the C and Python interfaces, the Java interface does not
currently allow the client to supply an EventImpl.  The problem is that
Java really has no way to interact with unix file descriptors so there's
no reasonable way to implement a fd-watching EventImpl in pure Java
(java.io.FileDescriptor doesn't do the trick since there's no way of
constructing one from raw (int) unix fd)[**].

So for now, I've had the Java bindings register an EventImpl when the
Connect class is loaded.  This EventImpl is a Java class, with native
methods implementing it.  In fact, I've simply stolen (verbatim) the
EventImpl from libvirt/qemud/events.c and made the native methods call
it.  [If we stick with this solution, it would obviously be better to
somehow share this code with libvirtd rather than copy it.]

The other tricky subject is multi-threading.  For now, I've avoided it
by exposing Connect.eventImpl.run_once() and forcing the client to call
it from their "event loop".  But the normal Java way of doing things
would simply run the EventImpl in a separate thread.  In fact, this
EventImpl does implement Runnable, which makes it trivial to run in a
separate thread -- but I don't declare that it implements Runnable yet
because it's not safe to run in a thread while another thread might be
making libvirt calls.

It shouldn't be hard to make this thread-safe using Java synchronized
methods and statements, but I haven't done that yet.  Should I??

** java.nio.Channel and friends seem to be the "right" interface for
exposing abstract "selectable channels" in Java.  It's just complicated
enough that I've avoided it for now.  But I can look into going this way
for allowing Java to provide an EventImpl in the future ..

Cheers,
Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: events-java.patch
Type: text/x-patch
Size: 26986 bytes
Desc: 
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20081107/1f0bfcd1/attachment-0001.bin>