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