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). > 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 :-\ 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list