Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E317EB3.9259E0A9@phekda.freeserve.co.uk> Date: Fri, 24 Jan 2003 17:58:11 +0000 From: Richard Dawe 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: <200301240901 DOT KAA06785 AT lws256 DOT lu DOT erisoft DOT se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. 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 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. [snip] > > 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 lame, but I have basically the same implementation as glibc and Cygwin. Or: why did I look at Cygwin? Because Eli asked how Cygwin does it. > As the licenses differ (I think), I'd be very wary of looking there. Well, I've done it now. I hadn't looked at them, when I wrote the original implementation. Besides, can't use the same algorithm, as long as we don't copy the code? Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]