[FFmpeg-devel] [RFC] Removing non-pthreads support

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Tue, Apr 20, 2010 at 11:45:54AM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> 
>> > On Mon, Apr 19, 2010 at 10:55:27PM +0100, M?ns Rullg?rd wrote:
>> >> Does a plain build, with dynamically linked systems libs, work
>> >> correctly?  Pure static builds can fail in crazy ways with glibc too
>> >> (thanks a lot, Drepper), so I'm not terribly concerned if this case
>> >> requires an extra hack or two.  What does the ffmpeg patch look like?
>> >
>> > Well, so far static builds seem to be working with 0 issues, at least
>> > MPlayer for Windows has since ages been a single binary.
>> > I'm already not happy about people having to install extra dependencies
>> > since it's such a pain for MinGW, and I really dislike if it's not working
>> > at all.
>> > I know none if this is "our" fault, but still.
>> > I don't fully understand why the maintenance burden for this is
>> > an issue now,
>> 
>> It's always an issue when we want to change something.  Right now, we
>> want to change something.
>
> I somehow missed what "we" want to change that would affect that code.

We're looking at making threading enabled by default and doing things
like detecting number of available CPUs.  This is much easier if we
only have to do it for pthreads.

>> > IIRC I was the last one to touch it and it was ages ago.
>> 
>> If it were not there, you would not have had to touch it.  As I
>> recall, you fixed something I'd accidentally broken due to not being
>> able to test it.
>
> Really? I though it was when I added support for a new threading model
> and then to fix a free I missed.

Maybe you did both.

>> > Contrary to the BeOS support the Windows support is at least
>> > something I can test...
>> 
>> Apparently both OS/2 and BeOS thread support are broken.  I think this
>> supports my assertion that they are a maintenance burden.
>
> Well... As I understood it they may never have worked.

All the more reason to remove at least those two.

> And there is no question it is a maintenance effort, I just think in
> the case of Windows it is a small enough to be justified by the higher
> convenience for users.

How is --enable-win32threads more convenient than --enable-pthreads?
The build environments we require come with pthreads already, so
there's no added burden there.

> Also (though you could see that as a bad thing) supporting more than
> one threading model could make people think twice before using pthread
> functionality that is bad portability-wise because it might be very hard
> to implement on top of other threading models.

Pthreads on win32 works well enough for us.  In the benchmarks someone
posted, there was no significant difference in the best times, and
pthreads performed better with more threads than cores.

Today, pthreads is by far the most portable threading system,
available on every major OS and most of the obscure ones.  If one day
we want to run on a system with a poor pthreads implementation, we can
always add support for something else when that happens.  I believe,
however, that it is exceedingly unlikely.

-- 
M?ns Rullg?rd
mans at mansr.com