[Top][All Lists]

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

[Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infras

From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure
Date: Tue, 23 Jun 2009 14:23:48 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 06/23/2009 01:32 PM, Daniel P. Berrange wrote:
+/* Asynchronous events main function */
+void monitor_notify_event(MonitorEvent event)
+    if (!monitor_ctrl_mode(cur_mon))
+        return;
+    assert(event<  EVENT_MAX);
+    monitor_puts(cur_mon, "* EVENT ");
+    switch (event) {
+    case EVENT_MAX:
+        // Avoid gcc warning, will never get here
+        break;
+    }
+    monitor_puts(cur_mon, "\n");

If a client is not reading from the monitor channel quickly enough, then
would this cause QEMU to block once the FD buffer is full ? A QEMU level
buffer might give more leyway, but we don't want to grow unbounded, so
ultimately we'll end up having to drop events. At which point you'd want
to send an event to the client indicating that the event queue overflowed,
so it can take remedial action to re-sync its state.

IMO relying on kernel buffers is sufficient here. An 8k buffer will hold hundreds of events. If the system is so congested that management cannot consume events rapidly enough, then it will also be so congested that guest vcpus will be starved.

Blocking on buffers full is acceptable IMO.

error compiling committee.c: too many arguments to function

reply via email to

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