From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNRkP-0000R1-FC for qemu-devel@nongnu.org; Mon, 28 Jul 2008 08:22:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNRkO-0000Q8-Ok for qemu-devel@nongnu.org; Mon, 28 Jul 2008 08:22:41 -0400 Received: from [199.232.76.173] (port=39245 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNRkO-0000Q4-Ls for qemu-devel@nongnu.org; Mon, 28 Jul 2008 08:22:40 -0400 Received: from mx1.redhat.com ([66.187.233.31]:49918) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNRkO-0006Pl-C0 for qemu-devel@nongnu.org; Mon, 28 Jul 2008 08:22:40 -0400 Message-ID: <488DB976.4030203@redhat.com> Date: Mon, 28 Jul 2008 14:20:06 +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: <48874D4A.8000604@codemonkey.ws> <48875849.60200@redhat.com> <200807231744.28969.paul@codesourcery.com> <48897D83.9020707@redhat.com> <20080725161714.GA11760@shareable.org> <488D8837.2090205@redhat.com> <20080728115929.GA7484@shareable.org> In-Reply-To: <20080728115929.GA7484@shareable.org> 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: qemu-devel@nongnu.org Cc: Paul Brook 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/