From e4f4bf95ac446e72f2c04770552cb2bc8590cfdd Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Tue, 27 Jan 2026 08:13:42 +0100 Subject: doc: update docs/nofork_noexec.txt Signed-off-by: Denys Vlasenko --- docs/nofork_noexec.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/nofork_noexec.txt b/docs/nofork_noexec.txt index 9d210a1c9..a20c1ec96 100644 --- a/docs/nofork_noexec.txt +++ b/docs/nofork_noexec.txt @@ -56,6 +56,11 @@ roughly are: (although usually xfunc_error_retval's state is not a problem). * do not expect that stdio wasn't used before. Calling set[v]buf() can be disastrous. +* the parent program's signal handlers will not be reset to SIG_DFL + (on exec, they are, but we avoid exactly that). + This means that signals will cause a part of _parent's code_ + to execute, and may cause EINTR returns from syscalls + in the NOEXEC applet code. * ... NOEXEC applets save only one half of fork+exec overhead. @@ -76,7 +81,7 @@ This poses much more serious limitations on what applet can do: hush shell only handles signals (like ^C) after you return from APPLET_main(). * do not ever exit() or exec(). - - xfuncs are okay. They are using special trick to return + - xfuncs are okay. They use special trick to return to the caller applet instead of dying when they detect "x" condition. - you may "exit" to caller applet by calling xfunc_die(). Return value is taken from xfunc_error_retval. -- cgit v1.2.3-55-g6feb