Superiority of processes over threads in gstreamer framework

[Baby Octopus]

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.