From owner-freebsd-hackers  Mon Dec  8 10:23:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA26584
          for hackers-outgoing; Mon, 8 Dec 1997 10:23:35 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26564
          for <hackers@freebsd.org>; Mon, 8 Dec 1997 10:23:22 -0800 (PST)
          (envelope-from tlambert@usr01.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id LAA06897;
	Mon, 8 Dec 1997 11:36:53 -0700 (MST)
Received: from usr01.primenet.com(206.165.6.201)
 via SMTP by smtp03.primenet.com, id smtpd006847; Mon Dec  8 11:36:43 1997
Received: (from tlambert@localhost)
	by usr01.primenet.com (8.8.5/8.8.5) id LAA23908;
	Mon, 8 Dec 1997 11:22:33 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199712081822.LAA23908@usr01.primenet.com>
Subject: Re: Why FIONREAD has no dual for write ?
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Mon, 8 Dec 1997 18:22:33 +0000 (GMT)
Cc: julian@whistle.com, hackers@freebsd.org
In-Reply-To: <199712080835.JAA28372@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 8, 97 09:35:06 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> What do we gain from this ?
> 
> We have a 20 years old interface (FIONREAD..) and I can understand that
> at that time some needs (e.g. synchronizing streams) were simply not
> there. Now we have new requirements and apps, and it would be appropriate
> to work on a common interface which is as device independent as
> possible.

IMO, the canonically "correct" thing to do would be to read and write
using a non-blocking descriptor.  This eliminates the multiple reader/
write buffer consumption races.

It's short, it's elegant, and you can still use "select()" for the
readability/writeability to avoid turning the program into a polling
loop.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.