Il 05/04/2012 13:18, Jan Kiszka ha scritto: >> > 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. > > Sorry, but that makes no sense to me. It is an abstraction we defined > for QEMU usage in a way that fits precisely our (current) needs. That's > what we did with tons of other abstractions before, so it fits very well > here IMHO.
EventNotifier _is not_ yet another thread synchronization primitive. It can be used across processes, across the user/kernel boundary, and the main loop can wait on multiple instances. QemuThread synchronization primitives are only usable within a process, cannot be passed to the kernel, and cannot signal the main loop. Besides, QemuEvent is no different from the existing EventNotifier, I don't think the churn introduced by the rename is justified. Paolo
