From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLdpG-0001PM-TV for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:52:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLdpF-0001Nb-A6 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:52:14 -0400 Received: from [199.232.76.173] (port=34874 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLdpF-0001NP-65 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:52:13 -0400 Received: from mx1.redhat.com ([66.187.233.31]:44621) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLdpE-0000lc-MK for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:52:12 -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 m6NCqCSh002145 for ; Wed, 23 Jul 2008 08:52:12 -0400 Message-ID: <48872979.4050107@redhat.com> Date: Wed, 23 Jul 2008 14:52:09 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. References: <488688E3.105@codemonkey.ws> <20080723082413.GA2291@redhat.com> <48871A7E.5030501@redhat.com> <20080723121510.GJ2291@redhat.com> In-Reply-To: <20080723121510.GJ2291@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org 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/