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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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)? 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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]