On Wed, Dec 17, 2008 at 01:24:11PM -0500, David Lively wrote: > Ok, with that fix, my asynchronous Java event implementation seems to be > working (though not fully tested) with these patches. > > But I'm not using connection cloning (yet). It's your concurrency > control in the remote driver that makes this work. That's good, but i just threw away the connection cloning patch. We're going to make asingle virConnectPtr object properly threadsafe. This will also mean you don't need 'synchronized' annotations on any java APis > On the Java side, domain event callbacks from another thread work > because of the (Java) locking of Connect objects. I don't think I > should remove that, since libvirt still prohibits concurrent use of the > same virConnect object (right?) Until 0.6.0.. > I suppose I could clone the virConnect object before delivering an event > to a Java Domain (so the Domain's Connect would wrap the clone). I > don't think this does much in the remote case (since the underlying RPC > pipe it still shared, albeit safely). But I suppose it might allow > greater concurrency in the non-remote cases. Is this what you had in > mind? I vote for not support events in another thread in Java until 0.6.0, when we can remove al the limitations on thread usage. 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