[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call to locale_charset within wcwidth

From: Daiki Ueno
Subject: Re: Call to locale_charset within wcwidth
Date: Fri, 06 Feb 2015 07:49:26 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Gavin Smith <address@hidden> writes:

> On Sun, Feb 1, 2015 at 10:07 AM, Daiki Ueno <address@hidden> wrote:
>> Eli Zaretskii <address@hidden> writes:
>>> Perhaps we could call _configthreadlocale to see if the value of
>>> setlocale can be cached?
>> Yes, but then we would need to hook setlocale to invalidate the cache,
>> and currently the setlocale module is not listed in the dependencies of
>> localcharset.  I'm wondering if it is worth adding the dependency for
>> this particular performance problem.  Perhaps it might be easier to add
>> a new API to localcharset for single-threaded / single-locale consumer.
> Here's a simple solution. The caller of the new function would call
> locale_encoding themselves and save the result. Maybe somebody will
> have a better idea. If this is too specialized to go into gnulib,
> would it be easy for a project to use its own replacement functions
> instead of the ones from gnulib?

>   int
> ! wcwidth_given_encoding (wchar_t wc, const char *encoding)

This will make consumers to replace all wcwidth calls with this new
function, which is good as a short-term solution and breaks consistency
with other similar functions, like mbrtowc.

By the above, I meant to add a new API to localcharset instead of
wcwidth, something like:

static const char *cached_locale_charset;

locale_charset_single_init (void)
  locale_charset_cached = locale_charset ();

and in locale_charset, always use locale_charset_cached if it is set.

Then you could invoke locale_charset_thread_unsafe at the beginning of
your program.  Once this workaround becomes unnecessary, we could make
this function nop.

Daiki Ueno

reply via email to

[Prev in Thread] Current Thread [Next in Thread]