Re: Thread specific data for GLib

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> yes, really not bad, I actually didn't think about something along those
> lines. in german we say: "gebranntes kind scheut das feuer" (burned child
> avoids the fire), because it really looks like the other rejected case,
> but it really is different. nifty. 

Yeah, its a bit tricky in that you can't safely use one 
piece of data to protect another piece of data, but you can 
use a piece of data to protect itself. 

(What I posted before was a bit overcomplicated - the hash
table is unnecessary, it is a leftover from earlier
attempts)
  
> > [
> >   You could also use the same basic strategy to build
> >   a non-locking version of your GStaticMutex, but
> >   I'm not convinced yet that the constructor
> >   functionality is worth the complexity
> > ]
> 
> I would like the constructor thingy, but it might not be necessary. OTOH
> it's not really more complicated than without, one argument, one
> comparison

My basis for thinking it is "not that useful", is that unless
there happens to be an existing argumentless constructor,
the choice tends to come down to something like:

===
static GHashTable *
get_specific_hash (void)
{
  static GStaticPrivate hash_private = G_STATIC_PRIVATE_INITIALIZER;
  
  GHashTable *hash = g_static_private_get (&hash_private);
  if (!hash)
    {
      hash = g_hash_table_new (some_func, some_func);
      g_static_private_set (&hash_private, hash);
    }

  return hash;
}

foo ()
{
  GHashTable *hash = get_specific_hash();
  [...]
}
===

and:

===
static GHashTable *
get_specific_hash (void)
{
  return g_hash_table_new (some_func, some_func);
}

static GStaticPrivate hash_private = G_STATIC_PRIVATE_INIT_FOR_TYPE (init_specific_hash, NULL);

foo ()
{
  GHashTable hash = g_static_private_get (&hash_private);
  [...]
}
===

The latter is admittedly a bit shorter, but IMO, not as clean. 
But that's just personal preference. I'll see what I can come
up with as a compromise.

> should I integrate your code into mine and make a new submission tomorrow,
> or how will we proceed....

I'll integrate our code today, and then check it into CVS on a
branch. (I think that will be easier than juggling patches.) Once we
decide we are reasonably happy with the setup, it can be merged to the
main branch.  (That actually needs to happen pretty soon.)

                                        Owen