There are thread-safety problems if we consider locale something
that can change ... the standard C library makes no provision
for handling the result of setlocale() in a thread-safe fashion
if another thread makes a call to setlocale().

But, if we assume non-threadedness, then something like:

 const gchar *new_lc_ctype = setlocale (LC_CTYPE, NULL);
 if (cached_lc_ctype && strcmp (new_lc_ctype, cached_lc_ctype) == 0)
   {
     return cached result
   }
 else
   {
     g_free (cached_lc_ctype);
     cached_lc_ctype = setlocale (LC_CTYPE, NULL);

     [ get result and cache it ]
   }

Probably is right for UNIX ... we can probably assume
 that LC_CTYPE always exists and a change in 
nl_langinfo() is always a result in a change in the LC_CTYPE
category. We don't need to worry about thread locking
since the libc interfaces aren't thread safe anyways.

(Does the uselocale() stuff in glibc-2.3 help the threading
issue? Or does it not matter if the app is still using
setlocale?)

*** Bug 95810 has been marked as a duplicate of this bug. ***

Sat Dec 14 20:11:41 2002  Owen Taylor  <otaylor@redhat.com>

        * glib/libcharset/{localcharset.[ch] libcharset-glib.patch}
        glib/gutf8.c: Break _g_locale_charset() into two pieces
        - a fast "raw" piece, and a slow "unalias pieces".
        Always call the "raw" piece, and call the unalias bit
        if it changes. Use a per-thread cache. (#79529)