[FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

[Jean-Yves Avenard]

On 8 January 2016 at 23:43, wm4 <nfxjfg at googlemail.com> wrote:
> Sorry, the problem you're trying to solve is just too ridiculous.

Welcome to the world wide web ! :)

> Threads might be the heaviest resource here, but no matter what you do,
> having hundreds of objects active at the same time (bring back geocity
> websites from the 90ies?) will cause a memory and CPU resource usage
> problem. So what if it fails on Windows XP.

You do know that people using a web browser typically have more than
one page or tab open at any given time.

I have about 75 opened as I'm writing this. Of course not all of them
have animated objects being displayed, but it's far from uncommon.

So have 30 video elements in one page, or 1 in 30 pages, it's kind of
the same issue.

Ever used facebook? see how many videos or animated objects you can
have in a discussion?

Luckily not everyone think it's a ridiculous problem to solve and just gave up.

Apple's VideoToolbox or Windows's WMF typically have a pool of
surfaces and threads they share internally.
I'm only suggesting that FFmpeg should consider doing the same,
because it has more potential use than old fashion media player that
only needed to worry about playing a single video at a time.

>
>> clearly haven't done much work on highly parallelised application, and
>> who fail to even consider the problem.
>
> Maybe you're trying to argue from some sort of theoretical point of
> view, but I'm thinking about practical issues, such as managing a
> global thread pool. Regardless of "parallisation", for the problem at
> this is also an overcomplicated and inefficient solution. Plus I didn't
> even completely reject the idea of having some sort of thread pool.

Have you ever used thread pools or task queue ? how could that ever be
over complicated or inefficient?
There are plenty of libraries providing them, heck you could use our
own XPCOM to do it.
As far as thread pools are concerned, it's very lightweight, far
easier to use than pthreads and extremely efficient (which I could say
the same for the rest of it).
You feed it with runnables and it run them as best as it can (either
sequentially or multiple at once if there are enough threads to
service them)

Please think about the problem more carefully, and reconsider.