[Top][All Lists]

[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: Avi Kivity
Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Tue, 04 Nov 2008 10:29:49 +0200
User-agent: Thunderbird (X11/20080723)

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.


1. run tcg code
2. block signals
3. pselect (enabling signals)
4. process pselect results (signals disabled again)
5. unblock signals
6. goto 1

Prior to Linux 2.6.16, pselect() was racy since it was implemented in userspace rather than the kernel. I don't think it's a problem now.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

reply via email to

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