octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #37591] system with async option results in zombie processes
Date: Fri, 22 Sep 2017 03:24:26 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

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.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]