[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-8.0 1/7] qemu/main-loop: Introduce QEMU_IOTHREAD_LOCK_GUA
From: |
Alex Bennée |
Subject: |
Re: [PATCH for-8.0 1/7] qemu/main-loop: Introduce QEMU_IOTHREAD_LOCK_GUARD |
Date: |
Mon, 21 Nov 2022 09:55:55 +0000 |
User-agent: |
mu4e 1.9.3; emacs 28.2.50 |
Richard Henderson <richard.henderson@linaro.org> writes:
> On 11/18/22 05:30, Alex Bennée wrote:
>> Richard Henderson <richard.henderson@linaro.org> writes:
>>
>>> Create a wrapper for locking/unlocking the iothread lock.
>>>
>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>>> ---
>>> Cc: Paolo Bonzini <pbonzini@redhat.com> (maintainer:Main loop)
>> You might want to review Paolo's comments from:
>> Subject: [RFC PATCH] main-loop: introduce WITH_QEMU_IOTHREAD_LOCK
>> Date: Mon, 24 Oct 2022 18:19:09 +0100
>> Message-Id: <20221024171909.434818-1-alex.bennee@linaro.org>
>> So it would be worth having the WITH_QEMU_IOTHREAD_LOCK() and
>> MAYBE_WITH_QEMU_IOTHREAD_LOCK() helpers for completeness.
>
> I don't see that (MAYBE_)WITH_QEMU_IOTHREAD_LOCK is particularly
> useful in any of the cases that I converted.
Fair enough - as long as they are easy enough to add later. The WITH_
forms do work nicely to wrap a particular area under lock and make
things visually clear vs the LOCK_GUARD which basically holds the lock
to the end of function or exit.
>
>> And of course the name cleanup.
>
> What name cleanup?
Also lots of bonus points for finally renaming these functions to
"*_main_thread" rather than "*_iothread" since, confusingly, iothreads
(plural) are the only ones that do not and cannot take the "iothread
lock".
>
>
> r~
--
Alex Bennée
[PATCH for-8.0 5/7] target/riscv: Use QEMU_IOTHREAD_LOCK_GUARD in riscv_cpu_update_mip, Richard Henderson, 2022/11/18
[PATCH for-8.0 4/7] target/ppc: Use QEMU_IOTHREAD_LOCK_GUARD in cpu_interrupt_exittb, Richard Henderson, 2022/11/18