Re: [PATCH V14 06/15] monitor: track IOThread users with QOM paths

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Sep 02, 2026 at 01:25:33PM +0200, Markus Armbruster wrote:
>> Zhang Chen <zhangckid@gmail.com> writes:
>> 
>> > On Tue, Sep 1, 2026 at 1:47 PM Markus Armbruster <armbru@redhat.com> wrote:
>> >>
>> >> Zhang Chen <zhangckid@gmail.com> writes:
>> >>
>> >> > Monitors that require an IOThread share the internal mon_iothread.
>> >> > Account for each monitor explicitly in IOThread holder tracking, using
>> >> > the monitor's canonical QOM path to distinguish holders.
>> >> >
>> >> > Acquire the shared monitor IOThread AioContext once, using the monitor
>> >> > QOM path as the holder, and reuse the stored context for later
>> >> > operations.
>> >> >
>> >> > Release the holder from the Monitor ObjectClass::unparent callback,
>> >> > while the canonical QOM path is still available. This covers every
>> >> > object_unparent() path and avoids duplicating the cleanup in
>> >> > monitor_cleanup() and monitor_qmp_prepare_delete().
>> >> >
>> >> > The internal mon_iothread remains hidden from query-iothreads, as before.
>> >> > Management applications therefore cannot use it to determine which
>> >> > monitors are using the IOThread. Nevertheless, track the monitor
>> >> > holders so that they follow the same explicit holder and
>> >> > IOThread reference lifecycle as other AioContext users.
>> >> >
>> >> > Signed-off-by: Zhang Chen <zhangckid@gmail.com>
>> >>
>> >> I have a question for our QOM experts (Paolo and Daniel).
>> >>
>> >> This patch takes a reference in its UserCreatableClass method
>> >> complete(), and relinquishes it in its ObjectClass unparent() method.
>> >> Is that correct and clean?  Or should complete() pair with
>> >> prepare_delete()?
>> >
>> >
>> > Add some background information in previous reviews for here:
>> > https://lists.gnu.org/archive/html/qemu-devel/2026-08/msg05318.html
>> 
>> Aha, Stefan asked for monitor_finalize(), which doesn't exist.  You then
>> moved it to the unparent() method.
>
> monitor_finalize() does exist as of about a month ago. It was
> introduced as part of my series that turned Monitor into a QOM
> object.

I was on an old branch.  Sorry for the noise!

>> My question for the QOM maintainers remains: is it okay to pair
>> complete() with unparent(), or should it pair with prepare_delete()?
>
> In general most things done in complete() can/should be undone in the
> finalize() callback IMHO.

I can't see a finalize() callback, and I *am* on current master now.  Do
you mean unparent(), or do you mean monitor_finalize()?

> prepare_delete() offers the opportunity to block deletion (ie prevent
> QMP  object_del from continuing), or (very rarely) to initiate some
> cleanup that needs to take place before object properties start getting
> deleted in the execution of finalize().
>
> I don't think 
>
> With regards,
> Daniel