Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd.

[Gerd Hoffmann]

Jamie Lokier wrote:
> 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.

Yes.

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

I want ptys behave as close as possible to tcp/unix sockets:

 * when nobody is connected, then don't send data.  Because we will
   block forever once the kernel buffer is full, which is bad.
 * when someone is connected, we want him get all data.  If the reader
   is too slow to keep up, that means we will block now and then, yes.
   Sockets do that too.

Additionally we can also try to drive the ptys / sockets / whatever
filehandles in non-blocking mode and try propagating the state back to
the guest so it stops writing.  That is a different issue, although
related.  IIRC the xen guys have some bits for that ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/