[RFC PATCH] kernel32: Use uselocale function to resture C locale for LC_CTYPE category.

[Ken Thomases]

On Mar 20, 2019, at 3:04 PM, Piotr Caban <piotr.caban at gmail.com> wrote:
> 
> On 3/20/19 8:52 PM, Piotr Caban wrote:
>> On 3/20/19 8:43 PM, Ken Thomases wrote:
>>> It would be better to not duplicate the locale objects for every thread (and leak them).  You can use static variables and one-time initialization.  And perhaps share them with the ones in kernel32, perhaps via libwine.
>> There's no leak, it's freed by glibc on thread/process destruction.
> Sorry, I've checked it wrongly. glibc only frees it for the main thread, it's leaked in other threads.

As it turns out, the macOS implementation works differently than Linux/POSIX.  Maybe that's common to BSDs generally, I don't know.

In macOS's C library, the thread locale is freed on thread exit, for all threads.  The thread locale is stored in a thread-specific key with a destructor.  There is some internal reference counting, but the locale object itself is freed unconditionally so that doesn't help us any.  So, my concern about leaking was misplaced, as was my suggestion to avoid duplicating the locale for every thread.  But now there's a concern about glibc.

Also, on macOS, newlocale() never modifies nor frees base.  The new locale is always newly-created and independent from base and base is left alone.  (Internally, it duplicates base to create the new locale and then modifies it as per the mask and locale string.)

So, global_loc is leaked on macOS.

Kind of a mess. :(

-Ken