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

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