[x265] xp support

[Steve Borho]

On Tue, Mar 25, 2014 at 6:00 PM, Roger Pack <rogerdpack2 at gmail.com> wrote:
> On 3/25/14, Steve Borho <steve at borho.org> wrote:
>> On Tue, Mar 25, 2014 at 11:25 AM, Roger Pack <rogerdpack2 at gmail.com> wrote:
>>> Hello.  I noticed in a recent discussion that seemingly windows xp
>>> support had been "dropped" to clean up code:
>>>
>>> http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?goto=newpost
>>
>> I would describe the situation more as we needed to use a
>> synchronization primitive (condition variable) in order to prevent
>> deadlocks and that primitive is not supported on XP.  This wasn't a
>> code cleanup, it was fixing a serious race hazard.
>>
>>> This does make it a bit painful for distributors who want to
>>> distribute (for instance) ffmpeg with libx265 support, but also still
>>> want to distribute "one executable" for all our users (including XP
>>> users)...
>>>
>>> Just throwing this out there, but maybe x265 can use pthread style
>>> condition variables then it be compiled against win32-pthreads project
>>> or what not, when needed.  Or something like that.
>>
>> Adding support for a second threading library on Windows just for XP
>> is a non-starter, but I would welcome a patch that adds an XP safe
>> ThreadSafeInteger class.  Option 3.3 from
>> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html looks to be a viable
>> solution, but it will be some time before this makes it to the top of
>> my TODO list.
>
> I guess my hope was that it coudl basically just be coded using
> pthreads (to support linux), then windows users would be required to
> provide a pthread library of their choosing...
> FWIW.

It is coded with pthreads on Linux/Mac but on Windows we are trying to
stick with native synchronization primitives.. which was fine until
late last week.

-- 
Steve Borho