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

[Gianluigi Tiesi]

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.

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

Regards


-- 
Gianluigi Tiesi <sherpya at netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/