qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGr


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGroup and helper functions
Date: Fri, 09 Aug 2013 16:59:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 09/08/2013 16:47, Alex Bligh ha scritto:
> 
> On 9 Aug 2013, at 15:35, Paolo Bonzini wrote:
> 
>> The point is that you can get rid altogether of TimerListGroup if you
>> just stick the array in the AioContext.  There's no use in adding a
>> concept with an easy plan to delete it, only waiting for someone willing
>> to do the work.  It is not related to anything that Stefan is
>> doing---the concept of TimerListGroup is introduced by this series.
> 
> I don't think that's correct. Timers currently operate only outside
> of AioContexts and that's what we're maintaining. You're saying
> make them work only inside AioContexts and add another AioContext
> to paper over the hole that's there because we have two nested
> event loops.

It's not papering over anything.

Timers right now are provided by the event loop.  If you make
AioContexts have timers, you can have a new AioContext for the timers
that the event loop handles before your patches.

It's not related to having two nested event loops.  The nested event
loops have the problem that timers do not run in them, but it's also a
feature---because you know exactly what code runs in the nested event
loop and what doesn't.  Using an entirely distinct event loop preserves
the feature.

> What I'm saying is if don't have 2 nested event loops
> (i.e. once Stefan has done his stuff),

I'm not sure at all that Stefan's work would remove the nested event
loops.  Perhaps that's the source of the misunderstanding.  But anyway I
don't think this is related to the nested event loops.  It is all about
not introducing an unnecessary indirection between AioContext and TimerList.

> we won't need the
> main_loop_tlg then, and removing it will be easy. What I don't
> want to do is have all the worry about breaking things I don't
> fully understand by requiring that everything has an AioContext
> that uses timers now.

There's nothing really to be worried about.  It is totally hidden to the
users that timers will go through an AioContext---just like it is
totally hidden that timers do not go anymore through an alarm timer.
Adding a new AioContext to the main loop is trivial, since an AioContext
is simply a GSource.  Your current series has much more scary surgery
than this!

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]