[FFmpeg-devel] [RFC] Removing non-pthreads support

[Ramiro Polla]

On Tue, Apr 20, 2010 at 7:15 PM, Gianluigi Tiesi <mplayer at netfarm.it> wrote:
> On Tue, Apr 20, 2010 at 11:02:19PM +0100, M?ns Rullg?rd wrote:
>> Gianluigi Tiesi <mplayer at netfarm.it> writes:
>> > On Tue, Apr 20, 2010 at 01:11:31PM -0300, Ramiro Polla wrote:
>> >> On Tue, Apr 20, 2010 at 1:04 PM, Gianluigi Tiesi <mplayer at netfarm.it> wrote:
>> >> > On Mon, Apr 19, 2010 at 11:29:44PM -0300, Ramiro Polla wrote:
>> >> >> this is my latest patch against pthreads-win32 CVS 20091019. compiles
>> >> >> and links and works fine with both gcc and msvc (the later was asked
>> >> >> by an ffms2 dev) and any combination of those 2. what it does is:
>> >> >> - remove the false wsock32 dependency
>> >> >
>> >> > the dep is not false :D
>> >>
>> >> would you care to reply to
>> >> http://sourceware.org/ml/pthreads-win32/2009/msg00053.html
>> >> with a reproducible testcase then?
>> >>
>> >> >> - remove the requirement for PTW32_STATIC_LIB to be defined for using
>> >> >> the library in mingw32 (like faac did)
>> >> >> - hint the linker (currently gcc and msvc) to run the initialization
>> >> >> code before main() or DllMain().
>> >> >
>> >> > declspec constructor/destructor
>> >> > are enough, just register pthread process attach/detch
>> >>
>> >> not if you want msvc interoperability.
>> >
>> > I doubt ffmpeg complies with msvc,
>>
>> This is a patch for pthreads-win32.
>
> :)
>
>>
>> > anyway I think an ifdef even more ugly
>> > would be preferred, attribute contructor/destructor is an exposed feature
>> > while adding directly functions to start and end may be subject to changes

>> Do you all agree it can be fixed? ?If yes, there is no reason to keep
>> win32threads support in ffmpeg.

Yes it can be fixed. But I'm not very happy with dropping win32
support yet. I'll run more benchmarks though, because to me it seems
pthreads-win32 should have an overhead.

x264 claimed they dropped win32 threads over pthreads-win32 because
the former was slower. Could whoever made those benchmarks please
share them with us? It would surprise me that a library which uses
win32 threads plus an overhead would be faster than win32 threads
directly.

> I use pthread static with the constructor trick since a lot of time
> in ffmpeg and mplayer without problems

You didn't understand. With my patch you can compile pthreads-win32
with MSVC or gcc, and link the resulting library with MSVC or gcc in
any order you want. using your constructor trick you can only build
pthreads-win32 and use it with gcc.