qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s


From: andrzej zaborowski
Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Tue, 4 Nov 2008 09:07:44 +0100

2008/11/3 Anthony Liguori <address@hidden>:
> Jan Kiszka wrote:
>>
>> Jan Kiszka wrote:
>>
>> There is a race between the alarm_timer firing SIGALRM and
>> main_loop_wait reaching the safe harbor of select (with that infamous 5
>> second timeout). If the signal comes when already blocked in select, it
>> will properly resume the latter immediately. But if the timer fired
>> BEFORE that point, host_alarm_handler will only set a flag that the host
>> timer has fired, the actual rearming will be done AFTER return from
>> select. Ooops....
>>
>
> Ah, so before this was causing the timer to potentially come 10ms later than
> it should have.  I was hoping that this change would shake out this stuff
> :-)
>
>> So, select should actually include the host timer as event. timerfd?
>> Unfortunately a recent Linux-only feature :-/. I don't think we can
>> rearm the timer from within the signal handler, at least not without
>> running all the pending qemu timers. And that is surely not a signal
>> handler job (qemu timer handler aren't thread-safe in general).
>>
>> Anyone any ideas? /me is thinking a bit more about it as well.

The select() man page on Linux mentions this race explicitely and
explains that pselect() is a solution.

>>
>
> host_alarm_handler should write to a file descriptor instead of setting a
> flag.  That file descriptor should then be select()'d on (just like we do
> for SIGUSR2 in block-raw-posix.c).

Or you can do this.

Cheers




reply via email to

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