Anthony Liguori wrote:
> 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.
>>   
> 
> 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).

A pipe, that slowly came to my mind as well. OK, will play with it.

Jan