Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

[Paolo Bonzini <pbonzini@redhat.com>]

Il 24/07/2013 09:31, Alex Bligh ha scritto:
> 
> 
> --On 24 July 2013 08:42:26 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> With ppoll, is this true or just hearsay?
>>
>> (Without ppoll, indeed setitimer has 1 us resolution while poll has 1
>> ms; too bad that select has other problems, because select has also 1 us
>> resolution).
> 
> Most 'reasonable' POSIX compliant operating systems have ppoll

Really?  I could find no manpages for any of Solaris and *BSD.

> and I would
> have thought there is /better/ resolution there than relying not only
> on signal, but also a pipe or eventfd plus the underlying poll().

I agree.

> If it was my comments you are referring to

The message I replied to was Ping Fan's, but perhaps you brought it up
first.  I don't know.

> , my concern was mainly about
> Windows (which I know very little about), as there does not appear
> to be a nanosecond or even microsecond alternative to
> WaitForMultipleObjects. However, articles like this:
> 
> http://social.msdn.microsoft.com/Forums/vstudio/en-US/e8a7cb1e-9edd-4ee3-982e-f66b7bf6ae44/improve-accuracy-waitforsingleobject
> 
> suggest that WaitFor{Single,Multiple}Objects can have pretty
> appalling latency anyway (100ms!), and there's no evidence that's
> limited by making one of the FDs (or objects) ready.

... especially when making one of the FDs ready would likely have the
same latency in some internal Windows thread that implements timers.

> In these
> circumstances, I'd question whether we gain anything by worrying
> about timer resolution.

Part of it should be fixed by os_setup_early_signal_handling.

This is corroborated by the fact that without
os_setup_early_signal_handling Wine always works, and Windows breaks.

Paolo