x264 and pthreads static initialization

[LoRd_MuldeR]

I noticed this from the pthreads changelog:

2010-06-18 Ramiro Polla <ramiro.polla at gmail.com >

* autostatic.c: New file; call pthread_win32_process_*()
libary init/cleanup routines automatically on application start
when statically linked.

The "autostatic.c" looks like this:

#if defined(__MINGW32__) || defined(_MSC_VER)

#include "pthread.h"
#include "implement.h"

static void on_process_init(void)
{
pthread_win32_process_attach_np ();
}

static void on_process_exit(void)
{
pthread_win32_thread_detach_np ();
pthread_win32_process_detach_np ();
}

#if defined(__MINGW32__)
# define attribute_section(a) __attribute__((section(a)))
#elif defined(_MSC_VER)
# define attribute_section(a) __pragma(section(a,long,read)); __declspec(allocate(a))
#endif

attribute_section(".ctors") void *gcc_ctor = on_process_init;
attribute_section(".dtors") void *gcc_dtor = on_process_exit;

attribute_section(".CRT$XCU") void *msc_ctor = on_process_init;
attribute_section(".CRT$XPU") void *msc_dtor = on_process_exit;

#endif /* defined(__MINGW32__) || defined(_MSC_VER) */

Question: Is the stuff in "x264dll.c" still needed? Will it even double initialize/deinitialize and break something ???

[LoRd_MuldeR]

Okay, after further investigation I can confirm that pthread_win32_process_attach_np() and pthread_win32_process_detach_np are called twice now.

So far it seems that this doesn't hurt. But I think it's superfluous, so I suggested the following patch:
http://pastie.org/1037905

[Dark Shikari]

Because, obviously, ffmpeg is the only application in the world that uses x264.

[LoRd_MuldeR]

Because, obviously, ffmpeg is the only application in the world that uses x264.

How is FFmpeg related here :confused:

What I wrote applies to every application that uses x264 as a DLL:
If the DLL was compiled with static pthreads, the initialization of pthreads will be done twice now (i.e. with pthreads 2010-06-18 and later).

Actually the x264 CLI encoder will initialize the static pthreads library twice as well

[MasterNobody]

There is more problems with new pthread than twice initialization (which is not big problem because it have guards for double initialization). Bigger problem came for static library from removing wsock32 dependence because this break x264's configure (and not only x264's) to understand that this is static library (it compiles without PTW32_STATIC_LIB define and other libraries) so PTW32_STATIC_LIB is not defined and pthread.h defines:
# define PTW32_DLLPORT __declspec (dllimport)

[LoRd_MuldeR]

Huh, I don't have this problem. My x264 "config.h" has:
#define PTW32_STATIC_LIB 1

Without that define the double initialization wouldn't happen, to begin with...

[MasterNobody]

Ops. Sorry. Then I was misinformed by komisar. Don't really test it myself :stupid:

[LoRd_MuldeR]

Ops. Sorry. Then I was misinformed by komisar. Don't really test it myself :stupid:

Maybe the problem only happens under certain circumstances.

All I can say is that I currently cannot reproduce it, neither with GCC 4.4.4 nor with GCC 4.5.1 or GCC 4.6.0 :confused:

But I can see that the dependency on wsock32 is gone...

[MasterNobody]

I tested and x264 correctly understand that this is static library (not static check fails with _imp__pthread_create). So probably I remember something incorrectly (may be he tell me about problems with ffmpeg compilation which don't check static library at all not x264) so forgot my incorrect post.