From 49e6bf2db92d896a71d08eb364069ba50fa82781 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Fri, 4 Aug 2017 14:28:16 +0200 Subject: sheel: improve comments on signal handling Signed-off-by: Denys Vlasenko --- docs/nofork_noexec.txt | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/nofork_noexec.txt b/docs/nofork_noexec.txt index cfb02145a..b45a4be89 100644 --- a/docs/nofork_noexec.txt +++ b/docs/nofork_noexec.txt @@ -64,15 +64,27 @@ This poses much more serious limitations on what applet can do: * do not use shared global data, or save/restore shared global data (e.g. bb_common_bufsiz1) prior to returning. - getopt32() is ok to use. You do not need to save/restore option_mask32, - it is already done by core code. + xfunc_error_retval, and logmode - it is already done by core code. * if you allocate memory, you can use xmalloc() only on the very first allocation. All other allocations should use malloc[_or_warn](). After first allocation, you cannot use any xfuncs. Otherwise, failing xfunc will return to caller applet without freeing malloced data! -* All allocated data, opened files, signal handlers, termios settings, - O_NONBLOCK flags etc should be freed/closed/restored prior to return. -* ... +* the same applies to other resources, such as open fds: no xfuncs after + acquiring them! +* All allocated data, opened files, signal handlers, termios settings + etc should be freed/closed/restored prior to return. + +Currently, ash shell signal handling is implemented in a way that signals +have non-SA_RESTARTed handlers. This means that system calls can +return EINTR. An example of such problem is "yes" applet: +it is implemented so that it has a writing loop, this loop is exited on +any write error, and in the case of user pressing ^C the error was EINTR. +The problem is, the error causes stdout FILE* object to get into error +state, needing clearerr() - or else subsequent shell output will also +not work. ("yes" has been downgraded to NOEXEC, since hush signal handling +does not have this problem - which makes "yes" to not exit on ^C (bug). +But stray EINTRs can be seen in any NOFORK under ash, until ash is fixed). NOFORK applets give the most of speed advantage, but are trickiest to implement. In order to minimize amount of bugs and maintenance, @@ -82,6 +94,8 @@ frequently executed from shell/find/xargs, particularly in shell script loops. Applets which mess with signal handlers, termios etc are probably not worth the effort. +Applets which must be interruptible by ^C in shells can not be NOFORKs. + Any NOFORK applet is also a NOEXEC applet. @@ -94,7 +108,7 @@ API to call NOFORK applets is two functions: First one is directly used by shells if FEATURE_SH_NOFORK=y. Second one is used by many applets, but main users are xargs and find. -It itself calls run_nofork_applet(), if argv[0] turned out to be a name +It itself calls run_nofork_applet(), if argv[0] is a name of a NOFORK applet. run_nofork_applet() saves/inits/restores option parsing, xfunc_error_retval, -- cgit v1.2.3