Superiority of processes over threads in gstreamer framework

[Wallacy]

And if the GCD (Grand Central Dispatch) was used?

libdispatch is under Apache 2.0 license and also proved to be very
efficient.


2013/3/12 David Schleef <ds at schleef.org>

> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130312/424d4ac1/attachment.html>