[PATCH] prevent retries on fclose/fflush after write errors

Mike Frysinger vapier at gentoo.org
Tue Mar 13 05:46:39 UTC 2012

On Sunday 11 March 2012 23:36:58 Rich Felker wrote:
> On Mon, Mar 12, 2012 at 01:50:27AM +0100, Denys Vlasenko wrote:
> > On Sunday 11 March 2012 18:10, Rich Felker wrote:
> > > On Sun, Mar 11, 2012 at 04:12:19PM +0100, Denys Vlasenko wrote:
> > > > On Sunday 11 March 2012 14:46, Denys Vlasenko wrote:
> > > > > I propose the following patch.
> > > > > Only compile tested by me, care to run-test?
> > > > 
> > > > A more correct (I hope) version:
> > > I'm curious why this is such a big patch introducing new functions and
> > > struct members. Couldn't it be just a one-line change in the function
> > > that writes out the buffers (i.e. do the buffer-voiding as soon as the
> > > error is hit rather than testing for it later)?
> > 
> > EINTR and EAGAIN should not result in output buffers being dropped.
> > You need to remember the error code for this.
> Why? I don't see any way an application could make use of this
> behavior to avoid losing data on EINTR or EAGAIN. As an application
> writer I would just treat any write error (or short write) from stdio
> as an unrecoverable situation. Even if some implementations might find
> a way to make it so an application could recover (I'd be interested in
> hearing if you have an idea how this would work...), I don't see any
> part of the standard that requires the implementation to behave that
> way, so an application depending on it would be non-portable.

treating EINTR/EAGAIN as unrecoverable is bad behavior for an app.  there are 
valid ways an app could receive either signal and have it be normal behavior.

having that handling be done in uClibc is not required by POSIX, but it's 
better imo for uClibc to carry a little bit more code there to provide better 
reliability to higher layers rather than forcing every userspace app to 
implement their own retry-on-eagain macros.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120313/9b0301ac/attachment.asc>

More information about the uClibc mailing list