[FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Michael Niedermayer]

On Tue, Oct 27, 2015 at 10:14:49AM +0100, wm4 wrote:
> On Mon, 26 Oct 2015 13:15:39 -0700
> Dale Curtis <dalecurtis at chromium.org> wrote:
> 
> > On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje <rsbultje at gmail.com>
> > wrote:
> > >
> > > So this is likely because we init all tables instead of just these that we
> > > need, right? So how about having one ff_once per table? That should be
> > > trivial to implement.
> > >  
> > 
> > (from the right account this time)
> > 
> > Just so we're all on the same page, this is trivial, but will get a bit
> > messy unless I'm missing something. The ff_thread_once() API only takes a
> > void(void) function, so unless there's partial specialization hiding
> > somewhere we need prototypes for each partial initialization. I.e.
> > ff_init_ff_cos_static_table_init_4(), ff_init_ff_cos_static_table_init_5(),
> > ff_init_ff_cos_static_table_init_6(), etc for 4..16. We would also then
> > have an array of AVOnce items for entries 4..16 where each entry would
> > correspond to calling the paired initialization function.
> > 
> > Is this what everyone had in mind?
> 
> Now that you're saying it, this is inconvenient. You could just
> initialize a static mutex (using AVOnce, since we don't have a static
> mutex initializer that works on all platforms), and guard
> initialization with this mutex.

hmm
but if we can create a static mutex portably with ff_thread_once()
then we could write a simple and portable API to do this

like:
FF_DECLARE_STATIC_MUTEX(my_mutex);

FF_INIT_STATIC_MUTEX(my_mutex);

the first would declare a mutex, AVOnce and a trivial init function to
create the mutex
the second would use ff_thread_once() to call that init function

that should hide all the complexity behind 2 lines of code

and it might be usefull elsewhere too


> 
> But I'd say this is not worth the effort, unless Michael disagrees?

I am not blocking/insisting on this, no but somehow it feels like
theres a more optimal solution


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151028/c50c4393/attachment.sig>