HI,
On Wed, January 9, 2019 9:12 am, Geert Janssens wrote:
> I like the idea of caching the system locale for future use. Too bad the
> std::locale is working so poorly on Windows :(
>
> Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
>> +const std::locale&
>> +gnc_get_locale()
>> +{
>> + static std::locale cached;
>> + static bool tried_already = false;
>
> If I understand it correctly using static variables makes the function
> unsuitable for multi-threading, right ?
Not necessarily. There is a race condition on first-use, but beyond that
I don't see a MT issue here. The data is read-only, right? Multiple
threads could read from the same read-only data simultaneously, so that
should be fine.
Static data is ont MT-unsafe if it's being changed on a per-call basis
(e.g. a time_t -> string API returning a static string buffer).
> Any idea how difficult would it be to fix that ?
You could add a mutex around the initialization. That's all I think you
would need here.
> I know GnuCash is not thread-safe by a long shot and gtk itself is single
> threaded so it doesn't matter that much.
>
> However I silently set a personal goal of changing that sometime. The C
> code
> is a lost cause IMO, but it might be worth to keep multi-threading in mind
> as
> we gradually convert to c++. In my basic understanding of threading this
> particular function should not be too hard to make tread safe.
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
