On Sat, May 02, 2015 at 12:04:31PM -0700, enh wrote: > On Wed, Apr 29, 2015 at 12:24 PM, Rob Landley <[email protected]> wrote: > > On 04/27/2015 11:26 AM, enh wrote: > >>>> it would also result in things like top(1) not exiting. > >>> > >>> If top is using stdio, it's easy to add a single ferror(stdout) check > >>> to the main loop. If it's using write(), it _must_ be checking for > >>> errors anyway since write can always return with a short/partial > >>> write. But top is unlikely to be hooked up to a pipe or socket anyway; > >>> it normally needs a terminal. > >> > >> the point is that then people need to think. if that were a plausible > >> solution, this thread wouldn't exist. the advantage of the signal > >> handler is that humans can keep on being humans. > > > > I _so_ should have called this project Dorodango. (See > > http://www.dorodango.com.) > > > > The point of this project is to do things right. I want to _fix_ > > everything I can. My insane cleanup review passes involve trying to find > > all this stuff and make sure we get it right. > > > > Sure, outside toybox yay sigpipe. But inside, the question is what the > > correct behavior should be. > > > > It sounds like android wants _exit(0) > > no, not particularly. we're arguing internally about whether SIGPIPE > is a crash or not. i think even undoing the dynamic linker's > installation of a crash reporter by setting it back to SIG_DFL would > be fine for toybox --- the real problem is that the dynamic linker > doesn't know whether it's dealing with an Android app (where you > probably do want the crash reporting) or a command-line tool (where > you probably don't), let alone corner cases like a command-line tool > that's implemented in Java.
In that case the crash-reporting signal handler setup should be in the Android app init code, not the dynamic linker, no? Rich _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
