[gst-devel] 0.9 proposals

[Benjamin Otte]

On Tue, 30 Nov 2004, Thomas Vander Stichele wrote:

> How do you make a non-blocking API out of a blocking API (say, a lib
> you're wrapping in an element) without using threads ?
>
I'd of course allow elements to spawn their own threads and care for them
if they need to. In reality I'd just consider libs that need their own
threads broken and work on a replacement.

> How would you write elements that are more performant or easier to write
> using threads, like the v4lsrc elements or multifdsink ?
>
v4lsrc is dead easy to write in a non-blocking way.

> How do you make up for the performance loss of choosing a non-optimal
> read/write/select model ?
>
Pardon me? I don't see a performance loss and a non-optimal select model.
In fact the biggest performance loss in my 0.9 code is the usage of
GMainLoop. I think this might be due to it's heavy use of locking, but I
haven't investigated it further.

> How do you still achieve low-latency if you have to actively loop to
> check for data processing ? How do you decide on the latency-vs-
> performance tradeoff ?
>
I'm not sure why you think this is so much better with threads. Threads
are just an uncontrollable and suboptimal way to have the decision what to
do next done by someone else and freeing you of the burden to decide for
yourself by making the kernel decide what to schedule next instead of
doing it yourself.
I've always wondered why that would be preferrable.

> I think nobody disagrees that the 0.7 cycle was a disastrous mess.
>
Actually, I do disagree. While it certainly could be improved, it was a
lot better than before.
But you're right that it would have been nice if people had actually
completed the stuff they wanted to do on time.

> But it should be possible to have *some* measure of
> stability and workingness throughout the development.
>
I think you'll have a hard time having this. To measure stability and
workingness, you need to do tests. GStreamer's testing framework is as abd
as during 0.7 and there's still the same crux with getting app developers
to switch their app and test it on an unstable branch that is quickly
evolving.
So I'm not sure which measurements you think of here.

Benjamin