[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overfl
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow |
Date: |
Mon, 28 Jan 2013 10:56:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
Il 25/01/2013 15:30, Stefan Hajnoczi ha scritto:
> Anthony, Paolo: Is there an alternative to select(2)? I think this was
> discussed a bit during the glib event loop integration.
>
> The two requirements I can think of are:
>
> 1. Portable so that we don't have to write OS-specific versions (epoll,
> kqueue, etc).
>
> 2. Sub-millisecond timeouts.
>
> Maybe we can use timerfd (and emulate it on non-Linux hosts) and then
> fully use the glib event loop?
Switching the alarm timer to a timerfd-based GSource is indeed easy. We
do not absolutely need sub-millisecond timeouts; non-Linux hosts can
just use poll's millisecond resolution in the GSource.
However, perhaps it would be good also to move the timer mechanism to
AioContext. Then qemu_new_timer becomes a special case of
aio_new_timer, just like qemu_bh_new. This would let BlockDriverStates
have timers that fire during a qemu_aio_wait(). It would fix the busy
waiting in bdrv_drain_all(), and it would help threaded device models
too. But more refactoring is needed for this.
> Internally glib prefers poll(2) but will fall back to select(2) on weird
> OSes. On Windows it has dedicated code.
The main obstacle for poll() is slirp, which likes to do random accesses
on fd_sets.
Perhaps it's a good topic for tomorrow's call.
Paolo