[gst-devel] fork() and then use gstreamer functions?

[David Schleef]

On Mon, Sep 14, 2009 at 01:59:04AM +0200, Alejandro Forero Cuervo wrote:
...
> The problem I'm having is that when I call fork(2) and, after setting
> a pipeline, the child process calls gst_bus_poll, the child process
> seems to be trying to interact with the X server!  Y get some
> assertion failures in xlib's code.  I'm guessing gst_bus_poll just
> calls the glib primitives for the main loop, which still have the
> gtk-dependencies.
> 
> I tried closing all files in the child (except the pipe used to talk
> to the parent and the standard error) but this just results in an
> assertion failure, Fatal IO error 9 (Bad file descriptor) on X server
> :0.0.
> 
> So what's a programmer to do in order to fork a process and use
> gstreamer functions without having the child process attempt to keep
> track of all the widgets and stuff?

You can't, at least in any useful manner.  You could attempt to
create a new GMainContext and main loop, and use those.  That
will prevent anything Gtk+ (or GStreamer) set up in the main
loop of the primary process.  Unfortunately, that's not the
only shared resource.

A reasonable scenario that cannot be worked around is that some
thread in the main process holds a global lock (which are common
in Glib and GStreamer) while another thread calls fork().  In the
child process, this lock will never be unlocked, which can cause
deadlocks.

Another reasonable scenario is that the program could be running
on an OS that doesn't support fork(), e.g., Windows.

The fork() system call (when not immediately followed by exec()) is
pretty useless in modern Unix programming.  I'd recommend using
a helper process, perhaps even the same executable with a
--special-flag, or even just a separate thread.



dave...