From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lrwcx-0001w1-Nx
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:57:19 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lrwcr-0001tj-Md
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:57:17 -0400
Received: from [199.232.76.173] (port=44327 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lrwcr-0001tf-Kf
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:57:13 -0400
Received: from mx2.redhat.com ([66.187.237.31]:49251)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1Lrwcr-0003sA-3L
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:57:13 -0400
Message-ID: <49DE1AD2.2060600@redhat.com>
Date: Thu, 09 Apr 2009 18:57:06 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com>
	<49DDAF9F.7040400@redhat.com> <49DDF807.1050707@us.ibm.com>
	<49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com>
	<49DE0042.9050103@redhat.com> <49DE0271.8090103@us.ibm.com>
	<49DE05F2.5060304@redhat.com> <49DE0673.3070501@us.ibm.com>
	<49DE081D.1030702@redhat.com> <49DE0CF2.3060307@us.ibm.com>
	<49DE1029.3030909@redhat.com> <49DE16DE.6030206@us.ibm.com>
In-Reply-To: <49DE16DE.6030206@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: libvir-list@redhat.com, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, Hollis Blanchard <hollisb@us.ibm.com>

Anthony Liguori wrote:
> Avi Kivity wrote:
>> I'm sorry, I don't see why.  It's just like a shell session.
>>
>> Compare with:
>>
>> Monitor 1:
>> (qemu) notify enospace on
>> (qemu) notify vnc-connect on
>> (qemu) notify migration-completion on
>> (qemu) migrate -d ...
>> (qemu) migrate_cancel
>> (qemu) migrate -d ...
>>
>>
>> Monitor 2:
>> (qemu) wait
>> vnc connection ...
>> (qemu) wait
>> enospc on ide0-0
>> (qemu) wait
>> migration cancelled
>> (qemu) wait
>> notification: migration completed
>>
>> There is no way to tell by looking what has happened (well, in this 
>> case you can, but in the general case you cannot).  You have to look 
>> at two separate interactive sessions (ctrl-alt-2 ctrl-alt-3 
>> ctrl-alt-3).  You have to keep reissuing the wait command.  Oh, and 
>> it's racy, so if you're interested in what really happens you have to 
>> issue info commands on session 1.
>
> How is it less racy?
>

Suppose you have a command which changes the meaning of a notification.  
If a notification arrives before the command completion, then it 
happened before the command was executed.  If it arrives after command 
completion, then it happened after the command was executed.

Oh.  If the command generates no output (like most), you can't tell when 
it completes.  I suppose we could have qemu print OK after completing a 
command.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.