Re: [RFC PATCH] fix select(2) race between main_loop_wait and qemu_aio_wait

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012-03-05 18:39, Avi Kivity wrote:
> On 03/05/2012 04:30 PM, Jan Kiszka wrote:
>> On 2012-03-05 15:24, Avi Kivity wrote:
>>>> Long-term, I'd like to cut out certain file descriptors from the main
>>>> loop and process them completely in separate threads (for separate
>>>> locking, prioritization etc.). Dunno how NBD works, but maybe it should
>>>> be reworked like this already.
>>>
>>> Ideally qemu_set_fd_handler2() should be made thread local, and each
>>> device thread would run a copy of the main loop, just working on
>>> different data.
>>
>> qemu_set_fd_handler2 may not only be called over an iothread. Rather, we
>> need an object and associated lock that is related to the io-path (i.e.
>> frontend device + backend driver). That object has to be passed to
>> services like qemu_set_fd_handler2.
> 
> Not sure I like implicit lock-taking.  In particular, how does it
> interact with unregistering an fd_handler?

I wasn't suggesting implicit lock taking, just decoupling from our
infamous global lock. My point is that thread-local won't help here.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux