> On May 19, 2026, at 4:31 PM, Robert Elz <kre%munnari.oz.au@localhost> wrote: > > Date: Tue, 19 May 2026 14:30:10 -0400 > From: Christos Zoulas <christos%zoulas.com@localhost> > Message-ID: <645CF0B9-1ADB-4DFC-B5BC-E9844896BC1F%zoulas.com@localhost> > > > | vfork() is temperamental. > > Yes, I know. Perhaps fortunately, at the minute, our shell doesn't > even really pretend to build outside NetBSD, so some of the issues aren't > relevant (something on my list to perhaps work on, if I ever find the time). > > | In some implementations the signal disposition is shared > | between parent and the vforked() child. > > Which is what I am dealing with at the minute ... if that isn't true of > NetBSD, then I have been (today) wasting some time - as I said, I can't > think of a good way to test this new issue (vfork() only problem). > > What would help all of this, the issue Taylor found, and this variant > related problem, would be if sigaction() had a SA_RESETFORK flag, to > cause the signal in question to be reset to the default (SIG_DFL) in the > child after a fork() (including vfork()). Want to add that? All these > issues could be made to simply vanish if that existed. > Perhaps it is time to ditch vfork() in sh and use posix_spawn() instead. Otherwise the only solution is to block the relevant signals and save the signal handlers bebore vfork() and then restore/unblock them once the child is done. christos
Attachment:
signature.asc
Description: Message signed with OpenPGP