[Top][All Lists]

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

Re: More weirdness with fork() in octave 5.1.0

From: Olaf Till
Subject: Re: More weirdness with fork() in octave 5.1.0
Date: Wed, 2 Oct 2019 15:49:39 +0200
User-agent: NeoMutt/20170113 (1.7.2)

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

> 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")
    disp("chl term")

    exit (0);


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

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).


public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: PGP signature

reply via email to

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