Re: [PATCH v5 32/35] monitor: add support for auto-deleting monitors upon close

[Markus Armbruster <armbru@redhat.com>]

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

> On Wed, Jul 01, 2026 at 08:32:06AM +0200, Markus Armbruster wrote:
>> marcandre.lureau@redhat.com writes:
>> 
>> >> The default monitor is usually a long lived object that will exist for
>> >> the entire lifetime of the VM. A monitor can only service a single
>> >> client at a time though, and so it might be desirable to hotplug
>> >> additional monitors at runtime for specific tasks. If doing that,
>> >> however, there is a need to remove the monitor when it is no longer
>> >> needed.
>> 
>> Whatever adds the additional monitor can also delete it.  The fact that
>> you propose other means suggests you believe this would be cumbersome in
>> practice.  Why?
>
> The use is is that someone/something wants to spawn a script that
> does some job with the QEMU monitor.  The thing that spawns the
> script adds the new monitor and launches the script. Having
> auto-delete means that you do not need to then keep track of that
> script to perform cleanup of the dynamically added monitor. It
> gives you "do the right thing" behaviour automatically when the
> script exits, closing its monitor connection.
>
> The initial series proposed by Christian supported the ability
> to run "object-del' on the monitor itself - a "self delete"
> essentially. That is very awkward from the code POV, as it
> required special case hanlding to ensure the QMP response to
> the delete action got sent on the socket before the delete
> action took place. It also made it impossible to then delete
> the character device.
>
> Auto-delete gives us a better solution with less code complexity.

I agree "self delete" is problematic.

I wonder how important the ability to fire and forget a script with a
dedicated monitor is.  I'd (naively?) expect whatever spawns the script
to reap its exit status.

If it is important, what about fire and forget a script with a dedicated
character device?  Can't come up with a use case for that within ten
seconds.  However, we use character devices for all kinds of crap.  Food
for thought, not a demand.

>> >> Allowing a client to run "object-del" against its own monitor adds
>> >> complex edge cases, as it would be desirable to send the QMP response
>> >> despite the monitor sending it being deleted. Doing "object-del" alone
>> >> will also result in orphaning a character device backend instance, as
>> >> there is no opportunity to run the companion "chardev-del" command.
>> >> 
>> >> A simpler way to ensure cleanup is to add the concept of auto-deleting
>> >> monitor objects. Specifically when the "CHR_EVENT_CLOSED" event is
>> >> emitted, the equivalent of "object-del" + "chardev-del" can be run
>> >> internally. Since the transient client has already droppped its
>> >> monitor connection, there is no synchronization to be concerned about.
>> 
>> If object-del or chardev-del fail, there's no way to report the error.
>> Can they fail?
>
> object-del can fail if
>
>  * An object with the specified "id" does not exist. That shouldn't
>    happen in this case but harmless if it odes.
>  * object_del command tries to delete the monitor that
>    is servicing the object_del command. Cannot happen with
>    auto-delete
>  * the monitor has not finished initializing it BH with
>    chardev handlers. Cannot happen if we know we have a
>    live connection already.
>
> chardev-del can fail if
>
>  * The chardev with "id" does not exist. SHouldn't happen
>    but is harmless if it does
>  * The chardev reports it is "busy" - aka the frontend
>    is still connected - we just deleted it so cannot happen
>  * Record/replay is in use - a niche use case
>
> So I don't think errors are a problem.
>
>> Do we always want to delete both monitor and character device?
>
> IMHO yes they are a pair whose lifetime should be tied together
> for normal use.

Would we make monitor auto-delete delete its character device if
character devices also had an auto-delete feature?

[...]