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: Alex Bligh
Subject: Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGroup and helper functions
Date: Sat, 10 Aug 2013 12:05:49 +0100

Paolo,

On 9 Aug 2013, at 15:59, Paolo Bonzini wrote:

> 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.

I've submitted a first cut as a separate patch just to see whether
it works:
  http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg01412.html

It passes 'make check' anyway.

I didn't wrap TimerListGroup into a separate struct for reasons
I'll set out below.

I think there are two ways to go here:

1. Wrap TimerListGroup into a separate struct, leave all the
   TimerListGroup functions in. This probably makes it easier if
   (for instance) we decided to get rid of AioContexts entirely
   and make them g_source subclasses (per Wenchao Xia).

2. Remove the TimerListGroup thing entirely and just have
   an array of TimerLists of size QEMU_CLOCK_MAX. I can
   leave the things that iterate that array inside qemu_timer.c
   (which I'd rather do for encapsulation). Part of the
   problem with the old timer code was that there were (in
   my opinion) far too many files that were working out what
   to iterate, and I really don't want to reintroduce that.

Despite the fact we both dislike the name TimerListGroup, I
think the way to go here is (1). (2) does not really save lines
of code (certainly not compiled instructions) - it's main saving
is removing a pile of commenting from include/qemu/timer.h,
which makes things more opaque.

I also think there may well be a use for something that wants
to use timers but not AioContext (I am thinking for instance
of a thread that does not do block IO). This permits that,
but does not require it.

WDYT?

-- 
Alex Bligh







reply via email to

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