[Octave-bug-tracker] [bug #37591] system with async option results in zombie processes

[Dan Sebald]

Follow-up Comment #13, bug #37591 (project octave):

I agree that callbacks are cleaner, generally speaking.  (At very low levels
like assembly instructions and specific architecture the equivalent is
interrupts.)  Polling isn't a good use of resources, and there is always the
question of how often something should be polled.  Plus, most system
environments and frameworks (Qt, etc.) have moved away from polling so the
programming of callbacks isn't challenging.

As for the severity of this zombie behavior, as noted, if forked processes do
in fact terminate taking all the memory along with it then it isn't much
consequence.  However, I could still imagine someone doing a very long batch
process that involves partial Octave code and then a system call to some other
program:


REPEAT(hundreds_of_files) {
  RUN_OCTAVE_PROCESSING;
  SAVE_RESULTS_TO_FILE;
  cmd = sprintf("post_process OUTFILE%d", i);
  system (cmd, [], "async");
}


Do this in a multi-user environment, e.g., mainframe, and the administrator
might look at the PID list and wonder what's happening.

Anyway, more importantly, the callback concept relates to signal handling,
which Octave never seemed to get quite right.  For example, we've often run
into problems with Cntrl-C, complicated by the fact there is a GUI present. 
And if the SIGINT were to be revamped, might as well look at SIGCHLD at the
same time.

For example, what is this "octave_quit()" starting to show up all over the
code?  I've looked at that function, and it appears that it traps the SIGINT
such that the SIGINT can only be handled by calling octave_quit().  If I'm
understanding correctly, that isn't very elegant programming, i.e., having to
remember to place an octave_quit() here and there.  There must be a better way
of dealing with SIGINT.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37591>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/