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

[Måns Rullgård]

Alexander Strange <astrange at ithinksw.com> writes:

> On Apr 19, 2010, at 5:22 PM, Howard Chu wrote:
>
>> M?ns Rullg?rd wrote:
>>> FFmpeg currently supports four different threading libraries:
>>> pthreads, beos, win32, and OS/2.  I suspect most people already use
>>> pthreads, and all the relevant operating systems seem to have a
>>> pthreads implementation, even OS/2.  I'm not sure about old BeOS, but
>>> I doubt anyone is still using that, much less with threads.
>>> 
>>> To ease the maintenance burden, I suggest we drop support for all but
>>> pthreads in FFmpeg.  If there is a compelling reason for keeping any
>>> of the others, please speak up now.
>>> 
>> Just out of curiosity, what pthreads implementation on Windows are
>> you referring to?
>
> This one:
> http://sourceware.org/pthreads-win32/
>
> Unfortunately the last release isn't perfect - if you use it as a
> static library you have to call some init code yourself.  pthread.c
> obviously doesn't do that since that's not required by pthreads, but
> some distributions patched it.
>
> Ramiro's Windows builds now use a patch against the library itself
> (autostatic) which gets rid of that, but I don't know if it's been
> applied upstream.  I hope it has since the idea of needing a local
> patch for this is gross and prevents switching to some other
> library.

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?

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