Re: bugs regarding late g_thread_init() calls

[Michael Meeks <michael meeks novell com>]

Hi Tim,

On Thu, 2007-01-04 at 12:56 +0100, Tim Janik wrote:
> which is exactly the problem. *if* we support it, we need to *fully* do
> that, i.e. keep supporting it.

	Nah; there is no need to fully support it, merely behaving like we did
in the past would be adequate for the legacy tail of people expecting
the old behavior surely ?
> please use diff -up for posting patches.

	Hokay, I did 'svn diff' which appears not to like options on svn head.

> >   if (!sys_page_size)
> >     g_slice_init_nomessage();
> > -  private_thread_memory = g_private_new (private_thread_memory_cleanup);
> > +  {
> > +    GPrivate *tmem = g_private_new (private_thread_memory_cleanup);
> > +    g_private_set (tmem, private_thread_memory);
> > +    private_thread_memory = tmem;
> > +  }
> 
> unless you meant to call thread_memory_from_self() here, to initialize
> the main thread allocator eagerly, this change doesn't make too much sense.

	Ah - I did mention this was somewhat 31337 ? ;-) my thinking goes that
if thread_memory_from_self is called -without- having inited threads
then 'private_thread_memory' will be set to the ThreadMemory pointer:

#define g_private_set(private_key, value) G_THREAD_CF (private_set, \
                                                       (void) (private_key = \
                                                        (GPrivate*) (value)), \
                                                       (private_key, value))

	ergo we transfer it to the (new) thread private memory (NB. if unused,
NULL is transfered), but I admit the behaviour is not at all obvious :-)
[ perhaps a cast would make it clearer ? ;-]

> i.e., did you want to write this?

	Something like this would work too, & perhaps be clearer. This leaks
though:

>    private_thread_memory = g_private_new (private_thread_memory_cleanup);
	^^^ trampled on the old ThreadMemory...
>    ThreadMemory *tmem = thread_memory_from_self();
>    g_private_set (private_thread_memory, tmem);
..
> i'm not sure we have to do the manual shuffling from Tor's patch at all
> though, i'd rather try to fix the g_private usage so it always does the
> right thing regardless of whether threading is initialized.

	Quite.

> > 	Of course, an early init for all gtk+ apps is a good solution that
> > should catch most cases; but take pity on ORBit2 that can be used in a
> > non-threaded scenario;
> 
> huh? does ORBit2 call gtk_init()?

	Nope; so we need a different solution.

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot