From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4Bu9-0007wq-4f for qemu-devel@nongnu.org; Tue, 20 Apr 2010 07:46:13 -0400 Received: from [140.186.70.92] (port=33407 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Bu4-0007sj-NY for qemu-devel@nongnu.org; Tue, 20 Apr 2010 07:46:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4Bu2-0004YC-Rm for qemu-devel@nongnu.org; Tue, 20 Apr 2010 07:46:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39000) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Bu2-0004Xj-Kf for qemu-devel@nongnu.org; Tue, 20 Apr 2010 07:46:06 -0400 Date: Tue, 20 Apr 2010 17:14:20 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback when write won't return -EAGAIN Message-ID: <20100420114420.GA20123@amit-x200.redhat.com> References: <1271319378-9811-1-git-send-email-amit.shah@redhat.com> <1271319378-9811-2-git-send-email-amit.shah@redhat.com> <1271319378-9811-3-git-send-email-amit.shah@redhat.com> <4BCD90C2.7050009@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCD90C2.7050009@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu list , paul@codesourcery.com On (Tue) Apr 20 2010 [13:32:18], Gerd Hoffmann wrote: >> static void tcp_chr_connect(void *opaque) >> { > >> + chr->write_blocked = false; >> s->connected = 1; >> qemu_set_fd_handler2(s->fd, tcp_chr_read_poll, >> - tcp_chr_read, NULL, chr); >> + tcp_chr_read, tcp_chr_write_unblocked, chr); > > This is wrong. You want register tcp_chr_write_unblocked only for the > chr->write_blocked == true (i.e. output buffers are full) case. > Otherwise qemu will burn cpu calling tcp_chr_write_unblocked. > > Yes, you'll have to call qemu_set_fd_handler2 each time write_blocked > changes state. Agreed. That's coming in the next round when I make it generic enough for all the backends to call the common code. > Also implementing the whole logic at the individual chardev drivers > level feels somewhat wrong as it will identical for most (all?) unix > chardev drivers. Yes, both these come together, I guess. I sent out this series as a "feeler" to see if the approach was acceptable. Paul didn't reply to my reply addressing his concern, so I take that as he's OK with the approach as well :-) Amit