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

Mike Frysinger vapier at gentoo.org
Wed Mar 14 05:33:09 UTC 2012


On Tuesday 13 March 2012 11:04:04 Rich Felker wrote:
> On Tue, Mar 13, 2012 at 01:46:39AM -0400, Mike Frysinger wrote:
> > 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.
> 
> Receiving a signal does not result in EINTR. Running a signal handler
> that was installed (intentionally) without SA_RESTART is what causes
> EINTR.

when i said "signal", i meant it as "indication" wrt the return value.  poor 
word choice.  so if you qualify your use cases, you could declare both these 
errnos as unrecoverable, but that doesn't make either so all the time.

> > 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.
> 
> Retrying on EAGAIN is simply *wrong*. It makes you consume 100% cpu.
> If the file descriptor is set as EAGAIN, it means whoever set it up
> wants to ensure that blocking does not happen; emulating blocking with
> 100% cpu load is the worst possible way to handle this situation! For
> stdio, EAGAIN must be treated as a hard error.

that's not the only possible way for EAGAIN to show up, but it's probably the 
only way that matters to us sitting on top of the Linux kernel and working 
with normal files.  so yeah, having the stdio not manually handle EAGAIN is the 
way to go.
-mike
-------------- 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/20120314/ef75ebea/attachment-0001.asc>


More information about the uClibc mailing list