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: Mon, 12 Aug 2013 19:27:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 11/08/2013 10:29, Alex Bligh ha scritto:
> Paolo,
> 
> --On 11 August 2013 09:53:38 +0200 Paolo Bonzini <address@hidden>
> wrote:
> 
>> There is actually a disadvantage of moving TimerListGroup to AioContext.
>>  The disadvantage is that GSources can only work with millisecond
>> resolution.  Thus you would need anyway some special casing of the
>> "timer AioContext" to get the deadline in nanoseconds.
> 
> We also need to special case the notifier as it needs to qemu_notify()
> rather than aio_notify().

No, not really, because qemu_notify_event() is exactly the same
aio_notify(main_loop_context).  You do not need to special case the
notifier even if TimerListGroup remains separate.

>> So let's keep the TimerListGroup for now.
> 
> OK - do you want me to wrap it in a struct? Other than that I think I've
> done all the comments in v8. Happy to do that with v10 if there are
> other comments on v9.

No, it's okay.  Unless you want to remove the callback and use
aio_notify everywhere.

> I note no one has yet commented on the changes to the icount stuff
> where a timeout is apparently arbitrarily capped at 2^31 ns (about
> 2.1 seconds) in PATCHv9 19/31 - attached below. That's the area
> I'm worried about as I'm not sure I understood the code.

Yes, that's ok.  I'm more worried about the thread safety, but it's not
a problem yet.

Paolo




reply via email to

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