From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:42207)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1TGVAJ-0001H2-Bu
	for qemu-devel@nongnu.org; Tue, 25 Sep 2012 09:27:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1TGVAD-0004kc-L4
	for qemu-devel@nongnu.org; Tue, 25 Sep 2012 09:27:07 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39255)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1TGVAD-0004kT-Cw
	for qemu-devel@nongnu.org; Tue, 25 Sep 2012 09:27:01 -0400
Date: Tue, 25 Sep 2012 10:27:50 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20120925102750.1d557bee@doriath.home>
In-Reply-To: <5060488A.1050008@redhat.com>
References: <87txunr76j.fsf@trasno.org>
	<5060488A.1050008@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] KVM call agenda for September 25th
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Bharata B Rao <bharata@linux.vnet.ibm.com>, "Richard W.M. Jones" <rjones@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, quintela@redhat.com

On Mon, 24 Sep 2012 13:48:26 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 24/09/2012 13:28, Juan Quintela ha scritto:
> > Hi
> > 
> > Please send in any agenda items you are interested in covering.
> 
> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> same code.

Case we're going to have the call (otherwise let's discuss it on the
list):

  - change blocking I/O to non-blocking I/O for qmp commands?

We have a few qmp commands that do blocking I/O (eg. screendump and
dump-guest-memory). Theoretically, those commands could block forever.
This is a more serious issue with the screendump command, which doesn't
stop vcpus.

I've never received a report about this, so maybe this is not an issue.
But, while the perfect solution here is to have async commands, I was
wondering if it would be feasible for synchronous commands like screendump
to be changed to use non-blocking fds. This way we don't risk blocking.