Daniel P. Berrangé <[email protected]> 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?
