On 30/12/2014 00:41, Peter Maydell wrote: > On 29 December 2014 at 20:27, Don Slutz <dsl...@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 <pbonz...@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 > >
