(In reply to Mike Hommey [:glandium] from comment #123)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> > I'd also be happy to drop support for G_SLICE=always-malloc on versions prior
> > to 2.32 if that makes the g_thread_init situation simpler. However, I don't
> > know whether it is acceptable to call g_thread_init after g_type_init in
> > versions prior to 2.24.
>
> g_thread_init can be called multiple times in versions >= 2.24, and gtype.c
> says, about g_type_init, "Since version 2.24 this also initializes the
> thread system". So if we're okay with dropping G_SLICE=always-malloc for
> versions 2.18 to 2.23 included, we should be able to get away with only
> calling g_type_init. Another option would be to just call
> g_slice_alloc/g_slice_free1, which will obviously initialize gslice, and
> after all, sounds much simpler.
>
> Thoughts?
There are many options, and I don't think it matters too much.
It looks like the pre-2.24 code at least attempts to deal with g_slice used
before g_thread_init [1], even though taking advantage of this would not be
complying with the docs.
The most safe would be to either version check or always
g_thread_init before g_type/g_slice usage, though it seems this is probably
not necessary.
It probably comes down to what is simplest.
My instinct is to avoid allocations where possible, so I'd tend to g_type_init
instead of g_slice_alloc because a g_type_init will be required at some
stage anyway, but that is likely premature optimization here if there
something simpler. g_type_init is a single symbol and g_slice_alloc would require finding two.
The new method in nsXULAppAPI.h can mean that everything can be done from there
with only a single GetSymbol(), if you want to keep the g_thread_init. It could be renamed to XRE_GLibInit() to do more than just g_thread_init.
Still I'm OK with dropping XRE_g_thread_init altogether and not bothering with
g_thread_init from XPCOMGlueStartup if you prefer.
(In reply to Mike Hommey [:glandium] from comment #123) always- malloc on versions prior always- malloc for alloc/g_ slice_free1, which will obviously initialize gslice, and
> (In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> > I'd also be happy to drop support for G_SLICE=
> > to 2.32 if that makes the g_thread_init situation simpler. However, I don't
> > know whether it is acceptable to call g_thread_init after g_type_init in
> > versions prior to 2.24.
>
> g_thread_init can be called multiple times in versions >= 2.24, and gtype.c
> says, about g_type_init, "Since version 2.24 this also initializes the
> thread system". So if we're okay with dropping G_SLICE=
> versions 2.18 to 2.23 included, we should be able to get away with only
> calling g_type_init. Another option would be to just call
> g_slice_
> after all, sounds much simpler.
>
> Thoughts?
There are many options, and I don't think it matters too much.
It looks like the pre-2.24 code at least attempts to deal with g_slice used
before g_thread_init [1], even though taking advantage of this would not be
complying with the docs.
The most safe would be to either version check or always
g_thread_init before g_type/g_slice usage, though it seems this is probably
not necessary.
It probably comes down to what is simplest.
My instinct is to avoid allocations where possible, so I'd tend to g_type_init
instead of g_slice_alloc because a g_type_init will be required at some
stage anyway, but that is likely premature optimization here if there
something simpler. g_type_init is a single symbol and g_slice_alloc would require finding two.
The new method in nsXULAppAPI.h can mean that everything can be done from there
with only a single GetSymbol(), if you want to keep the g_thread_init. It could be renamed to XRE_GLibInit() to do more than just g_thread_init.
Still I'm OK with dropping XRE_g_thread_init altogether and not bothering with
g_thread_init from XPCOMGlueStartup if you prefer.
[1] https:/ /git.gnome. org/browse/ glib/tree/ glib/gslice. c?h=glib- 2-22#n432