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