On 03/09/2018 03:00 AM, Peter Xu wrote:
Test the new OOB capability. Here we used the new "x-oob-test" command.
Firstly, we send a lock=true and oob=false command to hang the main
s/Firstly/First/
thread. Then send another lock=false and oob=true command (which will
be run inside parser this time) to free that hanged command.
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Signed-off-by: Peter Xu <pet...@redhat.com>
---
tests/qmp-test.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
+ /* Now, enable OOB in current QMP session, it should success. */
s/success/succeed/
+
+ /*
+ * Firstly send the "x-oob-test" command with lock=true and
s/Firstly/First/
+ * oob=false, it should hang the dispatcher and main thread;
+ * later, we send another lock=false with oob=true to continue
+ * that thread processing. Finally we should receive replies from
+ * both commands.
+ */
+ qmp_async("{ 'execute': 'x-oob-test',"
+ " 'arguments': { 'lock': true }, "
+ " 'id': 'lock-cmd'}");
+ qmp_async("{ 'execute': 'x-oob-test', "
+ " 'arguments': { 'lock': false }, "
+ " 'control': { 'run-oob': true }, "
+ " 'id': 'unlock-cmd' }");
+
+ /* Ignore all events. Wait for 2 acks */
+ while (acks < 2) {
+ resp = qmp_receive();
+ cmd_id = qdict_get_str(resp, "id");
+ if (!g_strcmp0(cmd_id, "lock-cmd") ||
+ !g_strcmp0(cmd_id, "unlock-cmd")) {
+ acks++;
+ }
+ QDECREF(resp);
+ }
Can you make the reply order deterministic? Perhaps by having the lock
command insert a sleep after locking but before replying, so that the
unlock always gets to reply first? But that can be a followup.
Reviewed-by: Eric Blake <ebl...@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
