On 30/12/2014 00:41, Peter Maydell wrote:
> On 29 December 2014 at 20:27, Don Slutz 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
On 12/29/14 18:41, Peter Maydell wrote:
On 29 December 2014 at 20:27, Don Slutz 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_NO
On 29 December 2014 at 20:27, Don Slutz 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)
On 12/29/14 04:59, Michael Tokarev wrote:
> 22.12.2014 18:04, Don Slutz wrote:
>
>> --- a/qemu-char.c
>> +++ b/qemu-char.c
>> @@ -1387,6 +1387,7 @@ static CharDriverState *qemu_chr_open_pty(const char
>> *id,
>> }
>>
>> close(slave_fd);
>> +qemu_set_nonblock(master_fd);
>>
>>
22.12.2014 18:04, Don Slutz wrote:
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -1387,6 +1387,7 @@ static CharDriverState *qemu_chr_open_pty(const char
> *id,
> }
>
> close(slave_fd);
> +qemu_set_nonblock(master_fd);
>
> chr = qemu_chr_alloc();
Hm. I'm not sure at all th
