Thread-safe nl_langinfo() and localeconv()

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Thread-safe nl_langinfo() and localeconv()
Date: 2024-08-13 05:45:14
Message-ID: CA+hUKGJqVe0+Pv9dvC9dSums_PXxGo9SWcxYAMBguWJUGbWz-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Over on the discussion thread about remaining setlocale() work[1], I
wrote out some long boring theories about $SUBJECT. Here are some
draft patches to try those theories out, and make a commitfest entry.
nl_langinfo_l() is a trivial drop-in replacement, and
pg_localeconv_r() has 4 different implementation strategies:

1. Windows, with ugly _configthreadlocale() and thread-local result.
2. Glibc, with nice nl_langinfo_l() extensions.
3. macOS/*BSD, with nice localeconv_l().
4. Baseline POSIX: uselocale() + localeconv() + honking great lock.

In reality it'd just be Solaris running #4 (and AIX if it comes back).
Whether they truly implement it as pessimally as the standard allows,
who knows... you could drop the lock if you somehow knew that they
returned a pointer to thread-local storage or a member of the locale_t
object.

[1] https://www.postgresql.org/message-id/flat/4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel%40j-davis.com

Attachment Content-Type Size
v1-0001-All-POSIX-systems-have-langinfo.h-and-CODESET.patch text/x-patch 3.5 KB
v1-0002-Use-thread-safe-nl_langinfo_l-not-nl_langinfo.patch text/x-patch 2.8 KB
v1-0003-Provide-thread-safe-pg_localeconv_r.patch text/x-patch 18.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-08-13 05:46:36 PG docs - Sequence CYCLE clause
Previous Message Bertrand Drouvot 2024-08-13 05:41:16 Re: Restart pg_usleep when interrupted