Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister

From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "jfehlig@suse.com" <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister
Date: Mon, 10 Dec 2012 10:19:26 +0000	[thread overview]
Message-ID: <1355134766.31710.119.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <20674.16214.934271.479230@mariner.uk.xensource.com>

On Fri, 2012-12-07 at 19:11 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister"):
> > Can we provide, or (more likely) require the application to provide, a
> > lock (perhaps per-event or, again more likely, per-event-loop) which
> > must be held while processing callbacks and also while events are being
> > registered/unregistered with the application's event handling subsystem?
> > With such a lock in place the application would be able to guarantee
> > that having returned from the deregister hook any further events would
> > be seen as spurious events by its own event processing loop.
> 
> I think this might be difficult to get right without deadlocks.

I took Bamvor's most recent response to mean that a per-event lock was
already in place in libvirt and inferred that this was the reason why
the originally proposed one line fix worked for them. Perhaps I
misunderstood?

Ian.