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