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
