[Toybox] default SIGPIPE handler that calls _exit(0)?
enh
enh at google.com
Sat May 2 12:04:31 PDT 2015
On Wed, Apr 29, 2015 at 12:24 PM, Rob Landley <rob at landley.net> 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.
using _exit(0) makes sense in toolbox where (a) you can pretty much
guarantee no writes are ever checked and (b) my time would be better
spent clearing whatever roadblock is keeping me from the toybox
equivalent.
> and everybody else wants sigpipe
> blocked and pipe full treated like disk full. I have a patch right now
> that'll do that, but this seems contradictory and I'd like to implement
> one consistent behavior if we can agree on what it should _be_...
i think blocking is fine for toybox on Android too, on the assumption
that we'll actually be paying attention and fixing the special cases
as they come up --- though to some extent people who do "top | head"
deserve whatever we choose to do to them.
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
1430593471.0
More information about the Toybox
mailing list