delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/01/24/13:47:59

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E318A46.7E764C3E@phekda.freeserve.co.uk>
Date: Fri, 24 Jan 2003 18:47:34 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: readv, writev [PATCH]
References: <200301241740 DOT h0OHeq309450 AT speedy DOT ludd DOT luth DOT se>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

ams AT ludd DOT luth DOT se wrote:
> 
> 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.

You can't do anything, but make it worse. This is one reason why it may be
better to do the write in one go - to fail "correctly".

[snip]
> > 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.

Possibly. I think being too proud is a bad thing - it blinds you from the bad
points. But perhaps that's the perfectionist in me speaking. ;)

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019