Re: [Qemu-devel] [PATCH] Fix alarm_timer race with select - v3

[Blue Swirl]

On 11/5/08, Jan Kiszka <address@hidden> wrote:
> [ changes: correct nfds initialization, more robust O_NONBLOCK setup ]
>
>  Changing the default IO timeout to 5 s (#5578) made a race visible
>  between the alarm_timer and select() in main_loop_wait(): If the timer
>  fired before select() was able to block, the full select() timeout could
>  have been applied instead of returning immediately. Since #5578, this
>  causes heavy problems to the Musicpal board emulation with stalls up to
>  5 s, but also with some older Linux guest kernels.
>
>  The following patch introduces a pipe that is written to by
>  host_alarm_handler and select()'ed in main_loop_wait(). This avoids
>  prevents that select() blocks though a timer has fired and waits for
>  processing.
>
>  Signed-off-by: Jan Kiszka <address@hidden>

>  @@ -1304,12 +1305,15 @@ static void host_alarm_handler(int host_
>                                 qemu_get_clock(vm_clock))) ||
>          qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
>                             qemu_get_clock(rt_clock))) {
>  +        CPUState *env = next_cpu;
>  +        char byte = 0;
>  +
>   #ifdef _WIN32
>          struct qemu_alarm_win32 *data = ((struct 
> qemu_alarm_timer*)dwUser)->priv;
>          SetEvent(data->host_alarm);
>   #endif
>  -        CPUState *env = next_cpu;
>
>  +        write(alarm_timer_wfd, &byte, sizeof(byte));

For the write case, we could save one initialization write access to
the "byte" for every alarm trigger if it's static const.