From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLdFT-0004YK-29 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:15:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLdFS-0004XZ-Gz for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:15:14 -0400 Received: from [199.232.76.173] (port=36985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLdFS-0004XE-DH for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:15:14 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55548) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLdFR-0002ZT-EH for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:15:13 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6NCFDvD021563 for ; Wed, 23 Jul 2008 08:15:13 -0400 Date: Wed, 23 Jul 2008 13:15:10 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. Message-ID: <20080723121510.GJ2291@redhat.com> References: <488688E3.105@codemonkey.ws> <20080723082413.GA2291@redhat.com> <48871A7E.5030501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48871A7E.5030501@redhat.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org 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. If you keep polling on the master PTY you'll just spin getting SIGHUP all the time. 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 :-( According to epoll(2), on FreeBSD you can use kqueue and on Solaris you can use /dev/poll. The PTY code isn't supported on Windows so that wouldn't neccessarily be a show stopper. Daniel -- |: 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 :|