On Wed, 07 Oct 2015 10:49:30 +0300 Rémi Denis-Courmont <[email protected]> wrote:
> Le 2015-10-06 20:43, wm4 a écrit : > > On Tue, 6 Oct 2015 12:41:13 +0200 > > Hendrik Leppkes <[email protected]> wrote: > > > >> The emulation uses native InitOnce* APIs on Windows Vista+, and a > >> lock-free/allocation-free approach using atomics and spinning for > >> Windows XP. > >> --- > >> This is in preparation to use pthread_once for global static init > >> functions, > >> and eventually removing the global lock in avcodec_open2 > >> > >> compat/w32pthreads.h | 68 > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 68 insertions(+) > > > > Somewhat related to this patch, we were discussing ways to deal with > > w32thread_init(). > > > > Personally, I think we should not have to litter the code with > > w32thread_init() calls. Nor should the user somehow have to make > > sure that this function is somehow called implicitly, when calling > > API functions which use threads. > > > > There are a few ways to handle this: > > > > 1. Don't handle it, but put it e.g. in avcodec_register_all(), and > > hope > > the user calls it before calling other APIs which might require > > it. > > 2. Call it from DllMain() only. This breaks static linking, or > > requires > > special care if an application uses a statically linked libav. > > 3. Make w32thread_init() thread-safe, and call it from all > > entrypoints > > that need it, like pthread_cond_init() and pthread_once(). > > 4. Remove the *run-time* Windows Vista+ support. People get to choose > the better Vista+ or the crappy NT5 CV implementation at build time. > > 5. Drop support for Windows 2003 and older completely. Even MSDN > started dropping documentation for it. > > Either way, the function is no longer necessary at all. > Both would work for me, but I think there has been resistance against this. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
