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 > -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list