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

[Gerd Hoffmann <kraxel@redhat.com>]

Daniel P. Berrange wrote:
> On Wed, Jul 23, 2008 at 01:48:14PM +0200, Gerd Hoffmann wrote:
>> Daniel P. Berrange wrote:
>>
>>> In the case of the PTY backend, the only time I'd expect data to be dropped
>>> is if there was no active slave open. If an application has the PTY open
>>> and is interacting, then I'd want to get all data.  
>> Yep, that would be most useful (and also matches what is done for tcp
>> for example).  Now the interesting question is:  How can qemu figure (in
>> a portable way) whenever there is some process listening on the slave side?
> 
> Well you get SIGHUP when the slave side closes, but the problem is then
> detecting the re-connect.

I don't see a SIGHUP.

Played around a bit with it (on linux) and found:

The write() syscall doesn't show different behavior.  It just queues up
data and either blocks or returns -EAGAIN when the buffer is full.  No
matter whenever someone is connected or not.

The read() syscall blocks or returns -EAGAIN when connected.  It returns
-EIO when unconnected (and flagged ready by select/poll).  So we can
detect disconnects that way.

> If you keep polling on the master PTY you'll just
> spin getting SIGHUP all the time.

Yep.  Well, I've seen it spinning getting -EIO, but thats pretty much
the same issue.

> On Linux you can deal with this by using
> epoll() in edge-triggered mode instead of poll which is level-triggered.
> Unfortunately epoll is Linux specific, so you'd need to have alternate
> impls of the guts of the QEMU event loop for every OS :-(

It is probably easier take the fd out of the polling loop and check now
and then using a timer.  Not perfect, but IMHO better that maintaining
three different poll implementations.

Which means we need our own code for ptys and can't use the generic fd
functions.  I'll go trying cooking up a patch ...

cheers,
  Gerd

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