Currently when QMP request queue full we won't resume the monitor until we have completely handled the current command. It's not necessary since even before it's handled the queue is already non-full. Moving the resume logic earlier before the command execution.
Note that now monitor_resume() is heavy weighted after 8af6bb14a3a8 and it's even possible (as pointed out by Marc-André) that the function itself may try to take the monitor lock again, so let's do the resume after the monitor lock is released to avoid possible dead lock. Signed-off-by: Peter Xu <[email protected]> --- monitor.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/monitor.c b/monitor.c index 1f83775fff..f5911399d8 100644 --- a/monitor.c +++ b/monitor.c @@ -4149,6 +4149,12 @@ static void monitor_qmp_bh_dispatcher(void *data) need_resume = !qmp_oob_enabled(mon) || mon->qmp.qmp_requests->length == QMP_REQ_QUEUE_LEN_MAX - 1; qemu_mutex_unlock(&mon->qmp.qmp_queue_lock); + + if (need_resume) { + /* Pairs with the monitor_suspend() in handle_qmp_command() */ + monitor_resume(mon); + } + if (req_obj->req) { trace_monitor_qmp_cmd_in_band(qobject_get_try_str(req_obj->id) ?: ""); monitor_qmp_dispatch(mon, req_obj->req, req_obj->id); @@ -4160,10 +4166,6 @@ static void monitor_qmp_bh_dispatcher(void *data) qobject_unref(rsp); } - if (need_resume) { - /* Pairs with the monitor_suspend() in handle_qmp_command() */ - monitor_resume(mon); - } qmp_request_free(req_obj); /* Reschedule instead of looping so the main loop stays responsive */ -- 2.17.1
