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?