From owner-freebsd-hackers  Tue Dec  9 07:20:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA09144
          for hackers-outgoing; Tue, 9 Dec 1997 07:20:20 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from chai.torrentnet.com (chai.torrentnet.com [207.87.46.100])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09132
          for <hackers@freebsd.org>; Tue, 9 Dec 1997 07:20:06 -0800 (PST)
          (envelope-from bakul@chai.torrentnet.com)
Received: from chai.torrentnet.com (localhost.torrentnet.com [127.0.0.1])
	by chai.torrentnet.com (8.8.6/8.8.5) with ESMTP id KAA09117;
	Tue, 9 Dec 1997 10:19:37 -0500 (EST)
Message-Id: <199712091519.KAA09117@chai.torrentnet.com>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc: hackers@freebsd.org
Subject: Re: Why FIONREAD has no dual for write ? 
In-reply-to: Your message of "Tue, 09 Dec 1997 05:57:11 +0100."
             <199712090457.FAA00305@labinfo.iet.unipi.it> 
Date: Tue, 09 Dec 1997 10:19:37 -0500
From: Bakul Shah <bakul@torrentnet.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Plus there are apps which want only to check the status of the queue in
> > a descriptor without actually doing the I/O, for whatever reason they
> > like.
> 
> This can be handled by POLL{IN,OUT}_WM.

> not sure how... if i get it right your changes can tell a process when
> you can transfer x >= WM bytes, but gives no clue about the current status
> of the queue. Much like the difference between

Well, if you want to know _exactly_ how many bytes you can
transfer without doing any IO, you are right that the changes
I propose wouldn't help.  But if you just want to know
whether you can transfer atleast N bytes, they are fine.
This is often good enough.  Also note that FION{READ,WRITE}
aren't precise either -- by the time you do actual IO more
data may have been received/drained.

[Just stating the obvious...] The idea behind high/low
watermark is to introduce a _hysteresis_ effect.  You want an
advance notice about when buffers may get empty/full so that
you can produce/consume sufficient data before they actually
get empty/full.  By choosing the watermarks judiciously you
can *minimize* the overhead and still keep data flowing.
This is something sorely missing from poll() and select().

-- bakul