On Wed, 28 Oct 2015 01:06:38 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Tue, Oct 27, 2015 at 10:14:49AM +0100, wm4 wrote: > > On Mon, 26 Oct 2015 13:15:39 -0700 > > Dale Curtis <dalecur...@chromium.org> wrote: > > > > > On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje <rsbul...@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 > Sounds very fine to me, though some might complain about potential memory leaks due to not freeing the mutex. (But at least on Linux, an unlocked mutex uses no OS resources. I'm not sure how it is on Windows, OSX, or other unixes.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
