No subject

generates a different thread through the GstTask API (from which chain
functions and the like are called). Reading the 
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-scheduling.txt
design document on scheduling  however, it seems that a new thread is
created only in specific conditions.
Specifically there's an example that bugs me:

 +---------+    +----------+    +------------+    +----------+
 | filesrc |    | identity |    | avidemuxer |    | fakesink |
 |        src--sink       src--sink         src--sink        |
 +---------+    +----------+    +------------+    +----------+
         (l-g) (c-l)      (g)  (l)          ()   (c)

   * fakesink has a chain function and the peer pad has no
     loop function, *no scheduling is done*.
   * avidemuxer and identity expose an (g) - (l) connection,
     a thread is created to call the sinkpad loop function.
   * identity knows the srcpad is getrange based and *uses the
     thread from avidemux to getrange data from filesrc*.

So here my two questions:
1) what exactly means that the fakesink-avidemuxer connection is not
scheduled? Is a new thread generated or not?
2) In regards to the identity-filesrc connection, what exacly happens? is a
new thread generated? If not, why? What are the general rules for thread
generation?

Finally It would be very appreciated if someone could explain to me how can
gstreamer scale when so many threads are employed... what about the
synchronization overhead? My guess is that in a streaming framework
synchronization overhead is unavoidable due to the need to synch the
streaming data itself, so the overhead for synching thread is somehow
"absorbed"...

Thank you very much,
Mirto

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/gstreamer-threading-internal-tp4428624p4428624.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.