[PATCH] prevent retries on fclose/fflush after write errors
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc