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:

[...]

>> >>  static void monitor_qmp_event(void *opaque, QEMUChrEvent event)
>> >>  {
>> >>      QDict *data;
>> >>      MonitorQMP *mon = opaque;
>> >>  
>> >> +    /* Protect against race if a client drops & quickly
>> >> +     * reconnects - we'll have the delete BH scheduled
>> >> +     * so must not honour a new open request
>> >> +     */
>> >> +    if (mon->delete_pending) {
>> >> +        return;
>> >> +    }
>> 
>> Consider "something happens between setting @delete_pending and monitor
>> destruction that triggers the event" and "same thing happens after
>> destruction".  Any observable differences in behavior?
>> 
>> Are there any other monitor interactions that might need similar
>> special-casing when @delete_pending?
>
> When the BH deletes the monitor object, it will disconnect the
> chardev handlers. So there is no possibility of monitor_qmp_event
> being called after the monitor QOM destruction is complete. The
> only race is between this method and the start of the BH.

Add this completeness argument to the commit message?