On 2012-04-05 14:48, Paolo Bonzini wrote: > Il 05/04/2012 14:04, Jan Kiszka ha scritto: >>> 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. >> >> Yes, QemuEvent can also be triggered externally - so could at least some >> of the other synchronization primitives if we had a use case for that. >> >>> Besides, QemuEvent is no different from the existing EventNotifier, I >>> don't think the churn introduced by the rename is justified. >> >> It is as EventNotifiers stood aside our synchronization infrastructure, >> and were only designed around vhost-net. This moves the concept in the >> center AND applies it broadly, including to the main loop. That "churn" >> is adoption to our naming and code organization scheme for >> synchronization primitives. > > But QemuEvent takes away the best name for a useful concept (a > cross-platform implementation of Win32 events; you can see that in the
The concept is not lost, it perfectly fit this incarnation. Just the special futex version for Linux is not feasible. > RCU patches which were even posted on the list). We already have a > perfectly good name for EventNotifiers, and there's no reason to break > the history of event-notifier.c. Have you measured if the futex optimization is actually worth the effort, specifically compared to the fast path of mutex/cond loop? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
