Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API

[Jan Kiszka]

On 2012-04-05 13:29, Paolo Bonzini wrote:
> 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.

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux