From owner-freebsd-current Fri Jan 10 12:46:10 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5529037B401; Fri, 10 Jan 2003 12:46:09 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB38B43ED8; Fri, 10 Jan 2003 12:46:08 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from heron (heron.mail.pas.earthlink.net [207.217.120.189]) by flavatown.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0AJv6V14942; Fri, 10 Jan 2003 11:57:06 -0800 (PST) Received: from pool0200.cvx22-bradley.dialup.earthlink.net ([209.179.198.200] helo=mindspring.com) by heron with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18X5Gp-0005wy-00; Fri, 10 Jan 2003 11:56:48 -0800 Message-ID: <3E1F252A.FD4098C5@mindspring.com> Date: Fri, 10 Jan 2003 11:55:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: Sam Leffler , current@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: Serious issues with kqueue on sockets on CURRENT. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a48a4ef2d9158f8af0e51a6da02960b6a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Lawson wrote: > On Fri, 10 Jan 2003, Sam Leffler wrote: > > What are "non-data characters"? > > A very zen question. :) In this case, It probably means bytes carried in > an mbuf with a type other than MT_DATA. Characters that won't come back from a read(2). The point of the EVFILT_READ character count is to provide a count of characters that could be retrieved via a subsequent read(2). So it seems that these include characters in mbufs of type MT_HE?ADER, if the data hung off ther is considered to be in the sockbuf. I still don't understand from the code if this is really a problem, or if it's just that there are a bunch of zero count EVFILT_READ events that end up popping back, along with non-zero-length ones. From my understanding of the complaint, it's that they are *all* zero length. The "child is waiting" seems to me to be indicating on which side of the pullup the event is sent (i.e. that the code was not changed to give correct results in the "already pending data" case), and that it can be fixed there, too. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message