FriBidiEnv (was: Re: [FriBidi] fribidi and shaping arabic
characters)
Behdad Esfahbod
behdad at cs.toronto.edu
Mon Jan 30 19:29:59 PST 2006
On Mon, 30 Jan 2006, Omer Zak wrote:
> On Mon, 2006-01-30 at 21:02 -0500, Behdad Esfahbod wrote:
>
> > * fribidi-run.c (free_runs, run_mem_chunk): Used if FriBidi is
> > not configured to use malloc for each run.
> >
> >
> > So, to make a thread-safe build of FriBidi with no static memory,
> > one can build without --disable-debug --enable-malloc, and don't
> > build the deprecated stuff... I'm going to add an option
> > --disable-depreacted for that. I may even make --enable-malloc
> > the default, but that's going to slow down FriBidi a bit, and
> > it's not really used with multi-threaded applications
> > currently...
>
> Looks to me like a regression in the case of multithreaded applications,
> which need to run FriBidi on more than one thread, and for which
> malloc() is too slow.
On desktop systems, FriBidi will be built with glib support, so
it will use the ultra-fast thread-safe slice allocator in the new
glib versions.
> FriBidiEnv was used not only to configure FriBidi operation but also for
> managing dynamic memory (structs which describe character runs).
Right, but imagine what happens if every small library has its
own memory management facilities...
> --- Omer
--behdad
http://behdad.org/
"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
More information about the fribidi
mailing list