[FFmpeg-devel] [RFC] Removing non-pthreads support
Tue Apr 20 00:04:19 CEST 2010
On Apr 19, 2010, at 5:55 PM, M?ns Rullg?rd wrote:
> 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:
>> 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
> 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?
I believe the dynamic library works fine.
Don't know why it's not in pthread.c - I think I asked Ramiro to try it but he'd already switched to patching the library.
More information about the ffmpeg-devel