> On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote:
>
> > On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
> >
> > > Lately, the data field for sockets, which holds bytes ready (in the
EVFILT_
> > > READ case) to be read, is computed to be zero. This means that if you
have
> > > a low watermark which is >0 per the kq, THE EVENT WILL NEVER HAPPEN.
Not to
> > > mention that this means when the event IS triggered properly (if you
can
> > > call it that), it is always said to have =ZERO= bytes ready.
> > [...]
> >
> > I can definitely reproduce this here and also fairly angry about it.
> > In addition to what you mentioned, fstat() gives an incorrect st_size
> > result now and it's likely that non-NOTE_LOWAT low watermarks are
> > firing too early as well.
> >
> > Ugly test program @ http://people.freebsd.org/~tjr/kq.c
>
> From what I can tell, mbufs with m_type == MT_HEADER can store data
> as well as those with m_type == MT_DATA. This patch corrects the
> tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data
> stored in MT_HEADER mbufs is not included in sb_ctl. I'd appreciate
> comments from people who have a good understanding of this code.
You're correct the MT_HEADER-type mbufs may have data in them. Using the
mbuf type to infer the type of data held within is probably a bad idea
unless the mbufs are specifically tagged as such. I'm not clear on exactly
what sb_ctl is supposed to count; the comment in the cvs log is unclear:
"Track the number of non-data chararacters stored in socket buffers so that
the data value returned by kevent()'s EVFILT_READ filter on non-TCP
sockets accurately reflects the amount of data that can be read from the
sockets by applications."
What are "non-data characters"?
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
