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

["andrzej zaborowski" <balrogg@gmail.com>]

2008/11/4 Jan Kiszka <jan.kiszka@web.de>:
> andrzej zaborowski wrote:
>> 2008/11/3 Anthony Liguori <anthony@codemonkey.ws>:
>>> 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.
>
> I think this is safer. Or what's the state of pselect on all supported
> platforms (including WIN32)?

Supposedly it's in posix, but no idea about win32.  Maybe the pipe is safer.

> My man page even warns that the Linux
> kernel is not implementing it yet, though I don't think this still
> applies to recent 2.6.2x kernels.

According to the man page it moved to kernel at 2.6.16 but the glibc
wrapper should be ok too.

Cheers