Il 05/04/2012 12:55, Jan Kiszka ha scritto: >> BTW you _could_ have a QemuEvent primitive based on Windows manual-reset >> events. It can be used in some cases as a replacement for condvars, >> especially when you have multiple producers and a single consumer (MPSC >> queue is perhaps the easiest lock-free data structure). It can be made >> very lightweight on Linux using futexes, and would also support timed >> wait easily on Windows. The API would be more or less like this: >> >> void qemu_event_init(QemuEvent *event, bool set); >> void qemu_event_wait(QemuEvent *event); >> void qemu_event_timedwait(QemuEvent *event, int ms); >> void qemu_event_set(QemuEvent *event); >> void qemu_event_reset(QemuEvent *event); > > Yes, qemu_event_wait/timedwait could be added on top later on when we > have a use case in sight. But mapping futexes wouldn't be compatible > with eventfd/pipe based signaling.
Note that the thing above would be separate from EventNotifier, which is why I only mentioned as "by the way". EventNotifier and anything using eventfd/pipes would _not_ be a "QEMU-styled thread synchronization mechanism" simply because you can use it with qemu_aio_set_fd_handler. That's why I think it should be separate from qemu-threads and stay outside the QEMU namespace. Paolo
