qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]