qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] monitor: Fix slow reading


From: Yury Kotov
Subject: [PATCH] monitor: Fix slow reading
Date: Fri, 22 Nov 2019 12:23:47 +0300

The monitor_can_read (as a callback of qemu_chr_fe_set_handlers)
should return size of buffer which monitor_qmp_read or monitor_read
can process.
Currently, monitor_can_read returns 1 as a result of logical not.
Thus, for each QMP command, len(QMD) iterations of the main loop
are required to handle a command.
In fact, these both functions can process any buffer size.
So, return 1024 as a reasonable size which is enough to process
the most QMP commands, but not too big to block the main loop for
a long time.

Signed-off-by: Yury Kotov <address@hidden>
---
 monitor/monitor.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/monitor/monitor.c b/monitor/monitor.c
index 12898b6448..cac3f39727 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -50,6 +50,13 @@ typedef struct {
     int64_t rate;       /* Minimum time (in ns) between two events */
 } MonitorQAPIEventConf;
 
+/*
+ * The maximum buffer size which the monitor can process in one iteration
+ * of the main loop. We don't want to block the loop for a long time
+ * because of JSON parser, so use a reasonable value.
+ */
+#define MONITOR_READ_LEN_MAX 1024
+
 /* Shared monitor I/O thread */
 IOThread *mon_iothread;
 
@@ -498,7 +505,7 @@ int monitor_can_read(void *opaque)
 {
     Monitor *mon = opaque;
 
-    return !atomic_mb_read(&mon->suspend_cnt);
+    return atomic_mb_read(&mon->suspend_cnt) ? 0 : MONITOR_READ_LEN_MAX;
 }
 
 void monitor_list_append(Monitor *mon)
-- 
2.24.0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]