[gst-devel] autoplugging and 0.9

[Ramón García]

Wingo,

(Apologize me if this has been already discussed).

If one has an element that blocks when asked for a
buffer (such as tcpsrc), a pipeline cannot work. If
the user issues a STOP command, the command will never
get the pipeline because it is busy reading from the
network.

An alternative could be that plugins use some complex
API so that all operations are non-blocking. But there
is only one GStreamer framework and many plugins; thus
it is better to have the complexity once in the
framework and not repeated in plugins.

In the design of Plan 9, some of the original
designers of Unix discovered that select() style
dispatching loops are complex. It is much better
programming with several threads.

This resembles me the discussion that we had about
MPEGs not working with the optimal scheduler. You
argued that it should be the job of the element to use
the clock asynchournously. But this makes it more
complex any element and any clock. It is in my opinion
better that the function gst_element_wait()
transparently saves the current context, and gives an
opportunity to run to other elements, and afterwards
returns to the caller. In this way, any streams with
buffers not sorted would be played correctly, without
adding complexity to several elements.

Well, talk is cheap and coding is difficult. I would
volunteer to do those changes if I could.
Unfortunately, I can't touch the optimal scheduler.

Ramon


		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es