Question

I am developing a GTK+ application for Linux that is launched from another GTK+ application using fork() and then execvp().

What I’m noticing is that the exec()’d application is taking around 10-15 seconds to complete the call to gtk_widget_show_all(). After this period of time, the widgets and window appear and the application runs perfectly.

So the invocation of the application looks like this:

main_gtk_ app -> fork() -> execvp( secondary_gtk_app ). secondary_gtk_app takes a long time to display window and widgets.

However, if I run the application directly, not exec()’d from the GTK+ application, from the command-line there is no delay in the gtk_widget_show_all() call.

Invocation:

shell command line: ./secondary_gtk_app ( start from command line , no delay in showing window and widgets ).

Does anybody know what might be causing this behavior? Or a way to perhaps reduce the length of time spent in gtk_widget_show_all()?

EDIT: After some research, it appears a large portion of the delay has to do with GTK+ doing some font initialization. If I run fc-cache -f which creates the font caches for the Fontconfig system on the embedded device before hand, the secondary_gtk_app loads in about 2 seconds. So it’s related to font handling.

Answer 1

Generally speaking, Gtk applications are not recommended to do fork(), but use the g_spawn_* function family instead.

Of course, you can call fork() if you really want or need, but you will have to take care at least of one important point: close all the file descriptors befor calling exec*(). If you fail to do this, the child process will inherit many (all) of the parent fds.

Note that a graphical application has at least one fd connecting it to the X11 server. And maybe even more…

For more details that you will ever want to know, you can see the source of the g_spawn_*() functions.