From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KNRO4-0007cV-0q
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 07:59:36 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KNRO2-0007cH-Kl
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 07:59:35 -0400
Received: from [199.232.76.173] (port=58281 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KNRO2-0007cE-FF
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 07:59:34 -0400
Received: from mail2.shareable.org ([80.68.89.115]:57550)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1KNRO2-0000Q7-9W
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 07:59:34 -0400
Date: Mon, 28 Jul 2008 12:59:29 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode
	for	qemu_chr_open_fd.
Message-ID: <20080728115929.GA7484@shareable.org>
References: <E1KJqa3-00067A-KN@mariner.uk.xensource.com>
	<48874D4A.8000604@codemonkey.ws> <48875849.60200@redhat.com>
	<200807231744.28969.paul@codesourcery.com>
	<48897D83.9020707@redhat.com>
	<20080725161714.GA11760@shareable.org>
	<488D8837.2090205@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <488D8837.2090205@redhat.com>
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: qemu-devel@nongnu.org
Cc: Paul Brook <paul@codesourcery.com>

Gerd Hoffmann wrote:
> > Btw, I've just tested.  In the initial state, the tty side never
> > opened, read() blocks and poll/select report that it's not ready for
> > read.
> 
> You still don't know whenever someone is connected or not.
> And thus you still don't know whenever the stuff you write to the
> tty is read out by someone or you risk to block when the kernel
> buffer is full.

That's no different from someone connected to the tty and not reading.

Is the problem that you want qemu to block when they do that?

> Also note that openpty() which is used by qemu gives you an open file
> handle for the tty side, so there is no "tty never opened" state.

Sure, but it's easy enough to use openpt(), grantpt() and unlockpt()
instead, as described in the Glibc manual.

-- Jamie