[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd.
Date: Thu, 24 Jul 2008 09:31:25 +0100
User-agent: Mutt/1.4.1i

On Thu, Jul 24, 2008 at 09:54:43AM +0200, Gerd Hoffmann wrote:
> Anthony Liguori wrote:
> > I really don't like introducing polling.  I think we should be trying to
> > reduce the overall number of wake ups in QEMU, not add more.
> Right now qemu wakes up quite often anyway, so it doesn't become worse
> (bad excuse, I know).
> > I'm inclined to say that we simply declare that reconnecting to a PTY is
> > broken/unsupported and strongly encourage the use of something else
> > (like unix sockets).  That's always been my understanding FWIW.
> It's not only reconnects, its also the initial connect.
> Right now qemu simply blocks once the pty output buffer is full.  With
> nobody reading this effectively means qemu blocks forever and doesn't
> responds any more to anything.  It can't stay that way IMO.
> I think we have three options here:
>   (1) Detect whenever someone is connected.  Drawback: needs polling
>       (unless someone comes up with a better patch).
>   (2) Run ptys in non-blocking mode.  Drawback: we risk loosing data
>       in case the pty reader is slow (also when nobody is connected of
>       course, but that is intentional ...).
>   (3) Drop pty support.  Drawback: we break existing setups.

NACK to that last option - I'd rather keep existing blocking behaviour,
than break existing applications using PTYs.

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]