Because this is a potentially valuable feature I don't see a reason to remove it.  It is true that, in general, callbacks are cleaner than polling protocols, but it is also dependent on the particulars of the design in question.

There are reasons to believe that this is not a tremendous problem for Octave.  First, there hasn't been a rash of bug reports reporting problems with resource usage.  Second, we know that the zombie process doesn't consume large amounts of memory, disk space, pixels, or some other finite resource.  Rather it takes up just a small amount of space in the process table.  There is a limit to the size of the kernel process table, but again it seems unlikely that Octave would be spawning hundreds of subprocesses.

Octave is all volunteer, so if this is the "itch" you want to scratch then go for it.  But to my mind there are many more impactful bugs that could be tackled first.

For this one, I think at least a first pass should be a documentation fix.  The docstring for system has no seealso link to waitpid, and there is no discussion at all about the repercussions of choosing "async".

Well, I'm sort of "thinking" more about this one right now rather than "acting".  I see in the synchronous case, Octave is using

  iprocstream *cmd = new iprocstream (cmd_str.c_str ());

one of the C++ interfaces to processes.  So, maybe that takes care of all the cleanup.  I see that is being used by _gnuplot_version_() to run gnuplot and inquire its version.  I don't see any zombie for that sub-process.

Maybe there is an asynchronous C++ interface that we could use instead of execl().

In any case, I've a feeling the proper way to do this is not the periodic reaping of processes in the background.  First, it seems like a rather complex hunk of code to deal with.  Second, we don't know how long these processes are going to last, so how do we tell when they are done?  I'd rather avoid thant.

I was thinking, after the discussion and patch for https://savannah.gnu.org/bugs/index.php?52084, that the most straightforward thing would be to handle that SIGCHLD interrupt when the process is complete.  By "handle", I mean THEN reap the sub-process; but in addition to that given what you've said in the previous two posts we could maybe add a callback function of some sort:

system('ls',0,'async',@callbackfunction);

where @callbackfunction is psuedocode for however the figures implement callback functions in which the arguments of the function should be the exit-status and so on.  The reaping would be done automatically, but the exit status info is present as Octave variables.

With such a setup, rather than you doing the polling approach on long processes, you could simply use callback functions for a much cleaner solution.  That sounds like better-placed effort to me.

Yes, there is nothing you can do in the child to influence this behavior, it has to be done by Octave.

If you are calling system directly, you can reap these defunct processes with

>> pid = system ("ls", [] "async")
pid =  16256
>> system ps;
  PID TTY          TIME CMD
16235 pts/0    00:00:00 octave-cli-4.3.
16256 pts/0    00:00:00 sh <defunct>
16259 pts/0    00:00:00 sh
16260 pts/0    00:00:00 ps
29689 pts/0    00:00:00 bash
>> waitpid (pid);
>> system ps;
  PID TTY          TIME CMD
16235 pts/0    00:00:01 octave-cli-4.3.
16307 pts/0    00:00:00 sh
16308 pts/0    00:00:00 ps
29689 pts/0    00:00:00 bash

I think this leads to the decision point of this problem, should system(..., "async") automatically reap all child processes automatically behind the scenes? Or should it be the responsibility of the caller, at the interpreter level, to call waitpid(pid) for every invocation of system(..., "async")?

It can't be done both ways. If Octave is in charge of reaping these defunct processes, then the caller will never have access to the exit status, etc, they will be truly async with no information available about whether they ever ran or are still running.

Actually, the shell "sh" probably is exiting with "-c" option.  The following terminal commands should illustrate:

sebald@ ~/octave/octave/octave $ sh
$ exit
sebald@ ~/octave/octave/octave $ sh -c "ls"
aclocal.m4
sebald@ ~/octave/octave/octave $

However, the execl documentation states:

"
Return Value

The exec() functions only return if an error has occurred. The return value is -1, and errno is set to indicate the error.
"

So, I've placed ";exit 1" at the end of the command.  That definitely causes different behavior, with error messages, but it still doesn't get rid of the forked processes.

I made some comments in thread https://savannah.gnu.org/bugs/index.php?52084 about "sh" hangs around after an asynchronous system().  Any insight into this?  It sort of makes sense that they should be there because Octave is launching a shell as follows:

  if (pid == 0)
    execl (SHELL_PATH, "sh", "-c", cmd, (char *) (0));

Notice there is nothing in that command that tells the shell (i.e., "sh") to exit once the command "cmd" is complete.  So, my thinking is that the shell is just sitting there.  I've attempted a couple things.  One, I tagged ";exit" on to the end of the command cmd, and two, made the change

    execl (SHELL_PATH, "sh", "-c", "-e", "-i", cmd, (char *) (0));

The -e is supposed to terminate if the system command fails (a good idea, as the user could type in any nonsensical words).  The -i is to force the shell to behave interactive, as the -c places the shell into non-interactive state.  I tried with and without the -i.  Basically, I can't seem to get that shell to terminate when it seems like it should be easy to do so.

In bug #42665, it was reported that Octave can also create gnuplot zombie processes if gnuplot is killed outside of Octave's knowledge. If Octave then tries to interact with the plot, it gets a broken pipe error and gets stuck somewhere, but this is a separate issue. If Octave subsequently closes the figure, the process is cleaned up.

Each call of

system (cmd, [], "async");

leaves a zombie process on Linux, probably MacOS and other unices as well. The sigchld_handler function is called for each process that exits, but nothing is done to clean up these processes until Octave exits. Exiting Octave simply allows init to clean up the leftovers.

Example:

octave:1> system ("ps");
  PID TTY          TIME CMD
  528 pts/3    00:00:00 lt-octave
 3357 pts/3    00:00:00 sh
 3358 pts/3    00:00:00 ps
19089 pts/3    00:00:00 bash
octave:2> system ("uname", [], "async");
octave:3> system ("uname", [], "async");
octave:4> system ("uname", [], "async");
octave:5> system ("uname", [], "async");
octave:6> system ("ps");
  PID TTY          TIME CMD
  528 pts/3    00:00:00 lt-octave
 3375 pts/3    00:00:00 sh <defunct>
 3377 pts/3    00:00:00 sh <defunct>
 3380 pts/3    00:00:00 sh <defunct>
 3384 pts/3    00:00:00 sh <defunct>
 3393 pts/3    00:00:00 sh
 3394 pts/3    00:00:00 ps
19089 pts/3    00:00:00 bash

A more common way to trigger this behavior is the edit command, which defaults to async mode when starting the editor.

If edit or system are called enough times, the user can overrun the process limit and no more processes can be started until Octave exits.