From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KMPdI-0000Vp-W4
	for qemu-devel@nongnu.org; Fri, 25 Jul 2008 11:55:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KMPdH-0000Tz-DV
	for qemu-devel@nongnu.org; Fri, 25 Jul 2008 11:55:04 -0400
Received: from [199.232.76.173] (port=60167 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KMPdH-0000Ts-5i
	for qemu-devel@nongnu.org; Fri, 25 Jul 2008 11:55:03 -0400
Received: from mail2.shareable.org ([80.68.89.115]:49554)
	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 1KMPdG-0003la-Om
	for qemu-devel@nongnu.org; Fri, 25 Jul 2008 11:55:02 -0400
Date: Fri, 25 Jul 2008 17:17:14 +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: <20080725161714.GA11760@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48897D83.9020707@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:
> Fundamental problem is there is no easy way to figure whenever we are
> connected or not.  Well, detecting the "connected -> disconnected"
> transition is easy, as read() starts giving us -EIO then.  The
> problematic case is the "(initial state | disconnected) ->
> (re-)connected" transition.  We have to try read() now and then to check
> whenever we still get -EIO or not.

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.

So the initial state is no problem, it doesn't need polling.

Only disconnected -> reconnected is a problem.

-- Jamie