[FFmpeg-devel] [PATCH 2/2] Autodetect pthreads

[Måns Rullgård]

Alexander Strange <astrange at ithinksw.com> writes:

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

I probably wouldn't oppose that.

> They don't seem really different from pthreads, except that they're
> missing some features like condition variables.

Except that pthreads doesn't exist on all systems.  Do OS/2 and Beos
have pthreads?  Not that I believe there are any users of those
systems.

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

I have no idea.

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