Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <018201c24d0b$aa2d26e0$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
References: <00c501c2496e$39ae2720$6132bc3e AT BABEL> <1029976536 DOT 27825 DOT 46 DOT camel AT lifelesswks> <025401c24a0d$1c996380$6132bc3e AT BABEL> <1030060087 DOT 8462 DOT 14 DOT camel AT lifelesswks> <20020824191035 DOT GB27153 AT redhat DOT com>
Subject: Re: readv/writev
Date: Mon, 26 Aug 2002 15:20:00 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> There shouldn't really be that much overhead to the current
method for
> handling text/binary reads, though.  It's just checking a bit
field.

At the coal-face it ends up being a bit more messy than that.  For
example, the fhandler::read code checks the readahead buffers for
pending data but they will always be empty in binary-mode (AFAIK)
. In fact there's a page of code before the check for whether a
binary read is being done and only then does the code escape back
to the caller.  Since (AFAIK) you can't change the text/binary
mode of an fd once it's been opened (and thus the readahead
buffers always empty in binary-mode), that escape could come right
at the top of the method.  Perhaps.

It might all be neater if a sysv streams-like approach were used:
that is, write a fhandler that does text->binary conversion and
vice-versa and "push" it on top of the raw (binary) fhandler if
it's opened in binary mode.  Then the base fhandler class wouldn't
have any text-mode stuff in it at all.

This sort of approach would then make it easier to override the
read/write stuff in derived classes as they wouldn't have to care
about text/binary mode at all.

Another point I was pondering was whether the buffering done in
the fhandler for text mode is Posix compliant.  That is, it makes
it possible for stuff to be written to a file and not be read by
another process (or thread, whatever) even tho' the two processes
perform some synchronization to make sure that the one reads after
the other has written.  It's probably not the world's most
important issue tho'.

My $0.02

// Conrad