Re: Call to locale_charset within wcwidth

[Daiki Ueno]

Gavin Smith <address@hidden> writes:

> It appears you can have thread-local variables with gcc using
> "__thread", for example, "static __thread const char *encoding". (I
> don't know about other compilers.) Would something like this work? As
> well as threads, updating the cached encoding when the encoding
> changes would be a problem.

If the overhead of a single setlocale call is acceptable, how about
using the return address of setlocale as a cache key and bypass the
later part?

Something like:

diff --git a/lib/localcharset.c b/lib/localcharset.c
index b4af28c..d0e10b9 100644
--- a/lib/localcharset.c
+++ b/lib/localcharset.c
@@ -491,6 +491,8 @@ locale_charset (void)
 #elif defined WINDOWS_NATIVE
 
   static char buf[2 + 10 + 1];
+  static __thread char *cached_codeset = NULL;
+  static __thread char *cached_locale = NULL;
 
   /* The Windows API has a function returning the locale's codepage as
      a number, but the value doesn't change according to what the
@@ -500,6 +502,9 @@ locale_charset (void)
   char *current_locale = setlocale (LC_ALL, NULL);
   char *pdot;
 
+  if (current_locale == cached_locale)
+    returned cached_codeset;
+
   /* If they set different locales for different categories,
      'setlocale' will return a semi-colon separated list of locale
      values.  To make sure we use the correct one, we choose LC_CTYPE.  */
@@ -609,5 +614,12 @@ locale_charset (void)
     codeset = "ASCII";
 #endif
 
+#ifdef WINDOWS_NATIVE
+  /* Cache the current locale as well as the determined codeset, so we
+     can bypass the call to GetACP and alias lookup from the next time.  */
+  cached_locale = current_locale;
+  cached_codeset = codeset;
+#endif
+
   return codeset;
 }

Regards,
--
Daiki Ueno