Superiority of processes over threads in gstreamer framework

[David Schleef]

GStreamer is pretty easily scalable across multiple processes or hosts.
It requires using one of several mechanisms to move data between the
processes or hosts, including gdppay/gdpdepay, tcp(server|client)(src|sink),
and shmsrc/shmsink.  The main tradeoff is efficiency -- you generally have
to copy and synchronize across process/host boundaries, which is not free.

OTOH, GStreamer is a pretty robustly written piece of software.  My
company has have systems in production with process uptimes of many
months, constructing and destroying 1000's of pipelines, as well as
systems with pipeline uptimes of several months.  Separating pieces
out into different processes would not be on my first page of ideas
for making the system more robust, since that would merely add complexity
that would need to be brought up to the same level of rigor before it
would add even a tiny amount of value.  In fact, we're doing exactly
the opposite: combining things into one process in order to have
great inter-module communication with a single type of logging and
crash dumping, instead of limited inter-process communication with
mixed types of logging.

Of course, doing this well requires rigorous engineering practices.  But
that's a vastly simpler task when the underlying framework already lives
up to that level.

(Also, everything Sebastian says in the other email about isolating
certain pieces of bad code is entirely true.)



David


On Tue, Mar 12, 2013 at 05:55:05AM -0700, Baby Octopus wrote:
> Hi,
> 
> Gstreamer framework has been well accepted in open source community and has
> been a well accepted product in terms of its flexibility and functionality
> as a media framework. I guess its 12 year old now
> 
> Was just wondering why one aspect has not been looked into as yet to make
> the framework more robust i.e., using processes instead of threads. A
> certain media pipeline can get really complicated with so many queue, tee,
> multiqueue and might lead to a large number of active threads. And in case
> if any thread crashes say for some reason, the whole pipeline collapses.
> This isn't an ideal situation to be in. Processes instead, will not make the
> complete pipeline to crash. Any crash in a process will lead to only that
> process to crash. And Inter process communication isn't that costly either
> since it can be handled at kernel level
> 
> So any particular reason here why thread is preferred over processes? It
> could also be true that its is just written that way without any reason. I'm
> just curious to know here
> 
> Please see that I'm not referring to any good,bad,ugly component here. I'm
> only referring to the gstreamer framework. 
> 
> ~BO
> 
> 
> 
> 
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Superiority-of-processes-over-threads-in-gstreamer-framework-tp4659072.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel