Fl::run() is child process

[Norman Goldstein]

I'm working in x86 linux. fltk 1.3.2.

Is Fl::run() expected to work in a child process (which I obtain via fork() )?
Searching the net, the answer seems to be, "no", but I am not certain.

My fltk code works fine in the parent process.  However, when I put all the
fltk code into a child process, the window is not properly displayed.

[Greg Ercolano]

On 06/26/14 11:41, Norman Goldstein wrote:
> I'm working in x86 linux. fltk 1.3.2.
>
> Is Fl::run() expected to work in a child process (which I obtain via fork() )?
> Searching the net, the answer seems to be, "no", but I am not certain.

You can if all the FLTK code is in the child.
This is a common way for an X windows app to background itself.
e.g.

int main() {
if ( fork() == 0 ) {
// Child
Fl_Window..
Fl_Button..
return Fl::run();
}
..parent..
}

Note: this /does not work/ on the mac.
You can't do a fork() without an exec() and still talk to the
window manager, as it severs the invisible "mach ports", and creates
random behavior.

On the Mac you /can/ do a fork() followed by an exec();
that preserves the mach ports, and allows your app to
background itself.

So for instance, if the app is invoked with no arguments,
you can fork() and exec() yourself ("recurse") passing the
child process a command line argument that tells your app it
can then do the FLTK init, so it can run the FLTK code in the child.

So probably best to do that (a fork() + exec()) so that your
app can work on both linux + OSX.

You definitely can't 'straddle' the code though, i.e. create
windows in the parent, then call Fl::run() in the child.

[Norman Goldstein]

It turns out that MathGL uses GOMP, and this has a publicized problem with fork().  So, I restructured my fltk code not do fork, but rather to create independent windows dynamically in the original process.  Thanks for the interesting response.