Hi Daniel -
When I apply these patches, I'm seeing segfaults on event delivery
when just running the existing synchronous
examples/domain-events/events-c/event-test.c (using the remote driver).
I've added a little debug. Apparently event->name is being NULLed out
sometime after the event is put on the queue:
DEBUG: remote_internal.c: remoteDomainEventFired (Event fired 0 3 1 1)
DEBUG: remote_internal.c: processCallRecv (Do 4 0)
DEBUG: remote_internal.c: processCallRecvLen (Got length, now need 64 total (60 more))
DEBUG: remote_internal.c: processCallRecv (Do 64 4)
DEBUG: remote_internal.c: processCallAsyncEvent (Encountered an event while waiting for a
response)
DEBUG: remote_internal.c: get_nonnull_domain (domain.name: dsl)
DEBUG: datatypes.c: virGetDomain (New hash entry 0x804c728)
DEBUG: domain_event.c: virDomainEventNew (event: 0x804c770 ->name: dsl)
DEBUG: libvirt.c: virDomainFree (domain=0x804c728)
DEBUG: datatypes.c: virUnrefDomain (unref domain 0x804c728 dsl 1)
DEBUG: datatypes.c: virReleaseDomain (release domain 0x804c728 dsl)
DEBUG: datatypes.c: virReleaseDomain (unref connection 0x804b040 4)
DEBUG: domain_event.c: virDomainEventQueuePush (event: 0x804c770 ->name: dsl)
DEBUG: remote_internal.c: processCallRecv (Do 0 0)
DEBUG: remote_internal.c: remoteDomainEventQueueFlush ()
DEBUG: domain_event.c: virDomainEventDispatchDefaultFunc (event: 0x804c770 ->name:
(null))
virGetDomain: name is NULL
Segmentation fault
I'll continue looking into it. But please let me know if you're
familiar with the problem ...
Thanks,
Dave
On Tue, 2008-12-16 at 10:24 -0500, David Lively wrote:
Hi Daniels -
Sorry for the delay. Life's been crazy. But now I'm finally looking
into using this series of patches with my Java event implementation
(which I've now redone via the java.nio.Select mechanism; ready to
submit pending resolution of the RPC concurrency issues). I should have
some feedback for you later today ...
Thanks,
Dave
On Tue, 2008-12-09 at 12:08 +0000, Daniel P. Berrange wrote:
> This series is a work-in-progress set of patches implementing connection
> cloning. The idea is that if you want to use a connection form multiple
> threads, you could do
>
> virConnectPtr copy = virConnectClone(conn)
>
> and use 'copy' from the other thread. This avoids the problem of having
> to make all the virError handling stuff thread-local whic is the blocker
> for allowing real mutlti-thread access to a single virConnectPtr object.
>
> I believe this cloning support should be sufficient for the Java bindings
> need to use a thread for its event loop. The idea being that if you wanted
> to use an event loop in a background thread, you'd create a cloned object
> for use event loop triggered callbacks like domain events notifications.
>
> I'd still like to do some experiments later making the single virConnectPtr
> fully thread safe, but that'll take a little more time. I'm hoping this
> cloning will address the Java needs right now...
>
> Daniel