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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 02, 2026 at 04:37:44PM +0200, Markus Armbruster wrote:
> 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()?

Sorry for the ambiguity. The latter.

When I wrote "finalize()" I meant to say "instance_finalize()", as the
generic name of the callback field in the Type, which is
"monitor_finalize()" in the specific Monitor implementation.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|