[FFmpeg-devel] [PATCH 2/2] Autodetect pthreads
Alexander Strange
astrange
Mon Apr 19 20:06:50 CEST 2010
On Apr 19, 2010, at 1:55 PM, M?ns Rullg?rd wrote:
> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>
>> 2010/4/19 M?ns Rullg?rd <mans at mansr.com>:
>>> David Conrad <lessen42 at gmail.com> writes:
>>>
>>>> On Apr 19, 2010, at 9:01 AM, M?ns Rullg?rd wrote:
>>>>
>>>>> David Conrad <lessen42 at gmail.com> writes:
>>>>>
>>>>>> Autoenable pthreads for libx264
>>>>>>
>>>>>> diff --git a/configure b/configure
>>>>>> index 959d63b..d2ec4c1 100755
>>>>>> --- a/configure
>>>>>> +++ b/configure
>>>>>> @@ -2579,6 +2579,11 @@ pthreads_if_any='
>>>>>> mpeg2video_encoder
>>>>>> '
>>>>>>
>>>>>> +# autoenable pthreads if the external lib is likely to depend on them
>>>>>> +if ! disabled pthreads; then
>>>>>> + enabled libx264 && enable pthreads
>>>>>> +fi
>>>>>
>>>>> This will break if any other threading lib is selected.
>>>>
>>>> Oops
>>>
>>> Seriously, this is getting uglier each time. What exactly are you
>>> trying to achieve?
>>
>> Currently, if a user compiles with --enable-libx264 without
>> --enable-pthreads, ffmpeg will break.
>
> Works fine with shared libx264.
>
>> This is stupid suboptimal behavior. Furthermore, there is no reason
>> ffmpeg shouldn't have pthreads by default,
>
> For those who do not want or need pthreads, enabling it by default
> will be an annoyance. Until you can make it read people's minds, it
> will always be wrong for someone. Changing the set of people it is
> wrong for without good reason is always silly.
>
> And once again, what about non-pthreads threading? If a system has
> several options, who are we to decide that pthreads is the preferred
> one?
I'd like to get rid of them. They don't seem really different from pthreads, except that they're missing some features like condition variables.
That means that there's no way to write threading code that's different from just using a pthread API library on top, and it duplicates algorithmic code if you try.
Is w32threads actually faster for slices than the pthread library most people use?
More information about the ffmpeg-devel
mailing list