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

[Reimar Döffinger]

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.

> > 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.

> > 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.
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.
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.