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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
