On Tue, Mar 25, 2014 at 6:00 PM, Roger Pack <[email protected]> wrote: > On 3/25/14, Steve Borho <[email protected]> wrote: >> On Tue, Mar 25, 2014 at 11:25 AM, Roger Pack <[email protected]> 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 _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
