From owner-freebsd-hackers  Mon Dec  8 16:45:58 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA05397
          for hackers-outgoing; Mon, 8 Dec 1997 16:45:58 -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 QAA05369
          for <hackers@freebsd.org>; Mon, 8 Dec 1997 16:45:12 -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 TAA06826;
	Mon, 8 Dec 1997 19:45:05 -0500 (EST)
Message-Id: <199712090045.TAA06826@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 "Mon, 08 Dec 1997 20:45:09 +0100."
             <199712081945.UAA29200@labinfo.iet.unipi.it> 
Date: Mon, 08 Dec 1997 19:45:05 -0500
From: Bakul Shah <bakul@torrentnet.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> I agree with the above, except that it does not work in all situations.
> E.g. I am not sure but does select() guarantee that you don't
> end up writing/reading one byte at a time ? I know in practice things
> are different, but there is no standard behaviour I think, so the risk
> is still there. In the audio driver I had to modify the behaviour of
> select() (block size) using a separate ioctl().

Perhaps one solution is to add an ioctl to set high/low
watermarks on a device and add new event bits POLLIN_WM and
POLLLOUT_WM for the poll() syscall.

In pollfd->events you set these bits instead of (or in
addition to) POLLIN/POLLOUT.  On return the corresponding bit
in pollfd->revents is set only if there are _greater than low
watermark_ bytes on input and _less than high watermark_
bytes on output.  This guarantees that you can transfer some
minimum number of bytes on read/write (provided you use the
O_EXCL mode).

This is a more general solution that allows finer control
over when to schedule IO and is useful in all sorts of
situations.

> 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.

Comments?

-- bakul