Fri 22 Sep 2017 04:20:57 AM UTC, comment #1:
- There's a zombie-like process bug which I will point out at the end of this post.
Interesting find. A little simpler way of illustrating is to do
as individual lines and as selecting the two and pasting--or use a function as follows:
versus
Perhaps this isn't as strange as it first appears. The two routines, system() and pause(), both ultimately go back to system functions.
system() with the 'async' option calls this functin:
pause() calls this function:
where nanosleep() is in <time.h>.
There are a couple plausible routes of investigations. I'm imagining somehow the end of the asynchronous process is triggering an end to the nanosleep. Is there something that is being sent back to Octave when the system() command completes that would wake the Octave process from sleep? Doesn't seem like it because the async system route forks a process to do the system command, and the execl() command would only know the forked process ID not the original Octave process ID. Is it possible that the pause() is getting placed in the forked process rather than in the Octave process?
Looking at the octave_async_system_wrapper() construct after the fork, something seems strange. There is a "retval = pid" in the case of the original Octave process, i.e., pid != 0. In the case of the forked process (pid = 0), there is a return value of -1 sent back. But where that is going to, I don't know, because the calling function just returns the return value of octave_async_system_wrapper(). It seems to me that the forked process should execute the system command and then simply quit.
Otherwise, it's a zombie process. Call
twenty or thirty times then look at the list of system processes and one will see a list of twenty "sh" processes. Well, technically they aren't zombie processes because if I exit Octave, all the "sh" processes terminate along with it rather than hanging around. But still, I'm wondering if something should be fixed there as well.
|