KSH hang in |spawnvex(3ast)|

[DavidMorano]

Just a reminder that if you see a hang from KSH (or another AST program) while it is in the "spawnvex(3ast)| subroutine it is most likely caused by LIBAST getting compiled with the use of
|vfork(2)|. When using VFORK, a program should pretty much just |exec(2)| after |vfork(2)|'ing.
This is just safe UNIX practice. But |spawnvex(3ast)| plays with the program signal mast (or some
such) after it has |vfork(2)|'ed but before it |exec(2)|'s. This can occasionally caused a hang on
some UNIX systems. The fix is to undefine some defines as follows in the |spawnvex(3ast)|
subroutine somewhere after the headers are included, with something like:

#undef _lib_vfork
#undef _real_vfork

Enjoy.

[krader1961]

The need for such #undef directives implies that the code needs to be refactored. But I would prefer to just remove the use of the posix_spawn() API. That API is so fugly that even a Microsoft software engineer would probably hate it.

[krader1961]

BTW, the intended use case for posix_spawn() is spawning "helper processes", not starting new process groups. Notably it doesn't provide the equivalent of setsid() and tcsetpgrp(). Which makes it a poor choice for shells like ksh. It's really meant to provide a cheap way for potentially large programs to run external commands without incurring the cost of duplicating its virtual memory structures (e.g., the process page tables).

While it is more efficient than fork() when the virtual process size is large that will not normally be an issue for a ksh process. And we still have to support fork() because posix_spawn() isn't available on all systems we want to support or is broken (e.g., on Cygwin). Also, note that on Linux it's actually implemented as a function not a syscall. On Linux we should be using clone(). And on other systems (e.g., BSD) we should probably be using vfork().

See https://bugzilla.redhat.com/show_bug.cgi?id=1295563 for another example of how posix_spawn() causes problems.

There was a long discussion about using posix_spawn() in the Go language: golang/go#5838. It looks like ultimately they chose to use the Linux clone() function.

[siteshwar]

@DavidMorano This issue was more of a candidate for wiki, but thanks for reporting it.

@krader1961 @DavidMorano Since we have removed support for vfork() through 6af5449, Can we close this issue ?

[DavidMorano]

@siteshwar

Since we have removed support for vfork() through 6af5449, Can we close this issue ?

YES - close.

As long as VFORK is gone, I am happy. This can certainly be closed now.
VFORK caused different problems on different OSes that it was selected to be used for in the KSH build process. It was always an error-prone interface. I just wanted it gone (for safety reasons as well as because of the various hangs or other problems it caused on some OSes). Good riddance.

[krader1961]

Closing as I've removed all mentions and uses of vfork from the code.