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

Alejandro Forero Cuervo azul at freaks-unidos.net
Mon Sep 14 11:45:39 CEST 2009

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

I find it sad that, from your first “reasonable scenario”, the fact
that GStreamer uses threads prevents me from using fork and then the
GStreamer functions.  I was under the impression that I would be able
to relatively ignore the heavily threaded nature of GStreamer from my
application, as it's documentation has misleading statements such as
“an application does not need to be thread-aware in order to use
GStreamer”.  If I wanted to use GStreamer in my application, I would
have to make it thread-aware to the point of not using fork(2) during
normal operation, which translates to forcing me to using separate
threads for certain things (ie. I need to scan directories or do DNS

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

I don't care about those OSs for my application.  :-)

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

I disagree.  I find it very useful.  Of course, if you've accepted to
use threads, sure, you then only need fork for a handful of cases.
However, some of us prefer to avoid threads in general, —and we don't
mind the propagandistic application of the adjective «modern» to «Unix
programming» to advocate the use of threads, we just counter it using
the «propagandistic» adverb, as you just saw.  :-) fork is very useful
for us.  But, to each his own: I don't want to start a flame war about
threads vs async-IO here.

I will check to see how difficult it would be to use a helper process
(which itself forks the processes that do the work and which
communicate with the main process over named pipes).  I wish I didn't
have to add all this complexity to my program just to use GStreamer.
:-(  In other words, I hope you can find a way to, eventually, make it
possible to use GStreamer from a forked son of a process that has also
used it.

Thanks for your help.  :-)


More information about the gstreamer-devel mailing list