From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60774)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Y8jhX-0006eg-GK
	for qemu-devel@nongnu.org; Wed, 07 Jan 2015 01:02:40 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Y8jhU-0006RR-42
	for qemu-devel@nongnu.org; Wed, 07 Jan 2015 01:02:39 -0500
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <54ACCBF6.6060408@redhat.com>
Date: Wed, 07 Jan 2015 07:02:30 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1419260640-2922-1-git-send-email-dslutz@verizon.com>	<54A125E6.4050807@msgid.tls.msk.ru>
	<54A1B945.20509@terremark.com>
	<CAFEAcA-GjRku9rRZr04itDx-bB40=DpdLNf9_V8QfHANiit4GA@mail.gmail.com>
In-Reply-To: <CAFEAcA-GjRku9rRZr04itDx-bB40=DpdLNf9_V8QfHANiit4GA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH 1/1] Do not hang on full PTY
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: Peter Maydell <peter.maydell@linaro.org>, Don Slutz <dslutz@verizon.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, Michael Tokarev <mjt@tls.msk.ru>, QEMU Developers <qemu-devel@nongnu.org>, Anthony Liguori <aliguori@amazon.com>



On 30/12/2014 00:41, Peter Maydell wrote:
> On 29 December 2014 at 20:27, Don Slutz <dslutz@verizon.com> wrote:
>> I was not sure on this being trivial also, but it looked like it could
>> be to me.  The uses of this FD all looked that they handle non-blocking.
> 
> Does g_io_channel_read_chars() definitely return G_IO_STATUS_NORMAL
> (and not, say, G_IO_STATUS_AGAIN) for an attempted read on a non-blocking
> fd with no data?

It should return G_IO_STATUS_AGAIN.  However, pty_chr_read() won't be
called in the first place because the fd won't be readable and thus the
chr->fd_in_tag GSource won't fire.

I think things more or less work right now just because PTYs are
buffered in the kernel and there's no network involved, but Don's patch
is good.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Michael, let me know if you're applying it yourself.

Paolo

> Otherwise pty_chr_read() is going to call
> pty_chr_state(chr, 0) which I think means "the other end has hung up"
> and will take the fd out of the main loop's poll set.
> 
> thanks
> -- PMM
> 
>