Re: More weirdness with fork() in octave 5.1.0

[Kay Nick]

Hi Olaf,

thanks so far for your reply.

Now I changed ftest.m according to your suggestions and it turns out,
that even more strange come up...

cat wb_ftest.m
printf("start\n");
ftest();
printf("stop\n");


cat ftest.m
function ftest()
  [pid msg]=fork();
  if (pid > 0)
    disp("par start")
    pause(3);
    disp("par term")
    waitpid(pid);
  elseif (pid==0)
    disp("chl start")
    pause(1);
    disp("chl term")
    exit(0);
  endif
endfunction


The added exit(0) statement in the child process seems to have no
effect. Adding it only does not kill the zombie. Adding the
waitpid(pid); statement in the parent process not only does not kill the
zombie either, it prevents the whole script from terminating (octave
won't display the '>>' on the command line). Octave remains irresponsive
and won't close when clicking on the 'x'-symbol. ;-(

Marcin




On 02.10.19 15:49, Olaf Till wrote:
> On Wed, Oct 02, 2019 at 02:43:00PM +0200, Dr. K. nick wrote:
>> cat wb_ftest.m
>> printf("start\n");
>> ftest();
>> printf("stop\n");
>>
>> cat ftest.m
>> function ftest()
>>   [pid msg]=fork();
>>   if (pid > 0)
>>     disp("par start")
>>     pause(3);
>>     disp("par term")
>>   elseif (pid==0)
>>     disp("chl start")
>>     pause(1);
>>     disp("chl term")
>>   endif
>> endfunction
>>
>> My procedure:
>>
>> 1. I start octave
>>
>> ps -Af | grep octave  (checking process list before running wb_ftest.m)
>> nick     1807    1071  0 14:18 tty2     00:00:00 /usr/bin/octave --gui
>> nick     1808    1807 97 14:18 ?        00:00:10
>> /usr/lib/octave/5.1.0/exec/x86_64-pc-linux-gnu/octave-gui --gui
>> nick     1823    1487  0 14:18 pts/3    00:00:00 grep octave
>>
>> 2. I run wb_ftest.m from command line
>>
>>>> wb_ftest
>> start
>> par start
>> chl start
>> chl term
>> stop
>>>> par term
>> stop
>> ps -Af | grep octave (checking process list wb_ftest.m has finished)
>> nick     1807    1071  0 14:18 tty2     00:00:00 /usr/bin/octave --gui
>> nick     1808    1807  7 14:18 ?        00:00:16
>> /usr/lib/octave/5.1.0/exec/x86_64-pc-linux-gnu/octave-gui --gui
>> nick     1863    1808  0 14:21 ?        00:00:00
>> /usr/lib/octave/5.1.0/exec/x86_64-pc-linux-gnu/octave-gui --gui
>> nick     1871    1487  0 14:22 pts/3    00:00:00 grep octave
>>
>> As it seems, last line in wb_ftest.m (printf("stop\n"); ) is being
>> executed twice although the 'pid==0'-part in ftest.m should have
>> finished (I'l like it to have finished) by this time. Is this intended
>> or a bug?
> It is expected behavior, the child process was generated within the
> function ftest(), but continues to exist after ftest() returns. The
> 'printf("sopt\n")' command is then executed both by the parent and the
> child, since it is displayed independently of the returned value of
> fork().
>
>> What would be the proper way to correct for this behavior?
> The proper way is to exit from the child after its work is done:
>
>   elseif (pid==0)
>     disp("chl start")
>     pause(1);
>     disp("chl term")
>
>     exit (0);
>
>  endif
>
> Note that using '_exit(0)' (available with the 'parallel' package)
> instead of 'exit(0)' may be preferable in the child, to bypass
> functions registered by Octave for being called at exit.
>
>> The process listings before and after running this script show, that a
>> new process is being fork()-ed correctly but it won't be terminated
>> (although the parent stays around longer than the child) properly. Even
>> after closing octave (clicking on x) the forked process stays around.
> The process will stay around as a so called 'zombie' process until the
> parent waits for it (with waitpid()).
>
> A note for which you didn't ask:
>
> fork() only replicates the current thread, which may cause problems in
> a multi-threaded program. Even if Octave is started without the
> graphical user interface, it may have more than one thread. Maybe the
> child process doesn't need the extra extra signal handling thread of
> recent Octave versions. But Octave may, e.g., use multi-threaded
> linear algebra libraries. If these generate their threads before the
> fork() call and the child process tries to use the generated threads
> (which won't be present in the child process then), there will be
> problems.
>
> For the 'parallel' package, work is underway to enable local parallel
> execution despite of this, using parallel Octave instances which are
> not just forked, but freshly started (with fork/exec on Unix and
> differently on Windows).
>
> Olaf
>