From: <ams AT ludd DOT luth DOT se>
Message-Id: <200301241740.h0OHeq309450@speedy.ludd.luth.se>
Subject: Re: readv, writev [PATCH]
In-Reply-To: <3E317EB3.9259E0A9@phekda.freeserve.co.uk> "from Richard Dawe at
 Jan 24, 2003 05:58:11 pm"
To: djgpp-workers AT delorie DOT com
Date: Fri, 24 Jan 2003 18:40:52 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamScore: s
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Richard Dawe:
> Martin Stromberg wrote:
> [snip]
> > Why do we want to fail the writev() call? It clearly succeeded in
> > writing the bytes it wrote from Entry 1.
> > 
> > I just don't get it.
> 
> By returning what the first write() wrote we are hiding the fact that the
> second write() failed. I'm worried that when the second write() fails, it
> might leave the file in a bad state. For normal files this is not a problem.
> But what about FSEXTs?

I can perhaps understand why you're worrying. However, so what? What
can you do? Any seeking or something trying to restore the state
before the failure is almost certain to make it worse.

> I think this is why I wrote writev to combine the data into one block of
> memory before writing.
> 
> It could be the reason behind these comments from glibc:
> 
> /* XXX I don't know whether it is acceptable to try writing
>    the data in chunks.  Probably not so we just fail here.  */
> 
> I'm not convinced that it's OK to return the results of the first write(), if
> the second write() fails. But I can't think of a good reason to convince
> anyone, so I'll shut up.

Well, how about that comment?... It sounds like it should be written
in one go.

> > > OK, now I'm slightly embarrassed. This is also the first time I've looked
> > > at the Cygwin source and they seem to use the memory allocation method
> > > too.
> > 
> > Why?
> 
> Why what? Why am I embarrassed? Because I've said my implementation was a bit

Why embarrassed? 

> lame, but I have basically the same implementation as glibc and Cygwin. Or:

Wouldn't that rather be sign to be proud? You came up with the same
solution that other clever (supposedly, i. e.) persons coded.


Right,

						MartinS