From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH 00/12] libxl: fork: SIGCHLD flexibility Date: Sun, 26 Jan 2014 22:39:28 -0700 Message-ID: <52E5F110.1020907@suse.com> References: <1389975845-1195-1-git-send-email-ian.jackson@eu.citrix.com> <52D9AECF.6050309@suse.com> <52DD678F.3070504@suse.com> <21214.37402.648941.864060@mariner.uk.xensource.com> <52DF57E2.2090602@suse.com> <52E09513.6060603@suse.com> <21216.62800.746512.422459@mariner.uk.xensource.com> <52E1EB97.4080007@suse.com> <21218.24466.92095.134875@mariner.uk.xensource.com> <1390567954.2124.85.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1390567954.2124.85.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xensource.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org Ian Campbell wrote: > On Fri, 2014-01-24 at 12:41 +0000, Ian Jackson wrote: > > >> Thread A Thread B >> >> invoke some libxl operation >> X do some libxl stuff >> X register timeout (libxl) >> XV record timeout info >> X do some more libxl stuff >> ... >> X do some more libxl stuff >> X deregister timeout (libxl internal) >> X converted to request immediate timeout >> XV record new timeout info >> X release libvirt event loop lock >> entering libvirt event loop >> V observe timeout is immediate >> > > Is there nothing in this interval which deregisters, pauses, quiesces or > otherwise prevents the timer from going off again until after the > callback (when the lock would be reacquired and whatever was done is > undone)? > The libvirt libxl driver will disable the timeout in libvirt's event loop before calling libxl_osevent_occurred_timeout. But AFAICT, and as Ian J. describes, another thread running the event loop could invoke the timeout before it is disabled. I think this could be handled in the libxl driver as described in my response to his mail. > (V is the libvirt event loop lock I presume?) > > >> V need to do callback >> call libxl driver >> >> entering libvirt event loop >> V observe timeout is immediate >> > > Given the behaviour I suggest above this would be prevented I think? > > >> But if you think about it, if you have 10 threads all running the >> event loop and you set a timeout to zero, doesn't that mean that every >> thread's event loop should do the timeout callback as fast as it can ? >> That could be a lot of wasted effort. >> > > It doesn't seem all that likely triggering the same timeout multiple > times in different threads simultaneously would be a deliberate design > decision, so if the libvirt event core doesn't already prevent this > somehow then it seems to me that this is just a bug in the event loop > core. > If I understand the code correctly, it does seem possible to trigger the same timeout multiple times. > In that case should be addressed in libvirt, and in any case the libvirt > core folks should be involved in the discussion, so they have the > opportunity to tell us how best, if at all, we can use the provided > facilities and/or whether these issues are deliberate of things which > should be fixed etc. > Agreed. I'll mention the issue and this discussion on the libvirt IRC channel tomorrow. Regards, Jim