| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GUC thread-safety approaches |
| Date: | 2025-11-18 22:15:02 |
| Message-ID: | 863f8394-0a22-4bb7-ba4c-8ae126d16907@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18.11.25 15:15, Heikki Linnakangas wrote:
> PS. I found this blog post on how Thread Local Storage is implemented on
> different systems very enlightening: https://maskray.me/blog/2021-02-14-
> all-about-thread-local-storage. I think whatever scheme we come up with
> will be a home-grown implementation of one the methods described in that
> article.
I read this:
> Windows TLS
> Referencing a TLS variable from another DLL is not supported.
>
> __declspec(dllimport) extern thread_local int tls;
> // error C2492: 'tls': data with thread storage duration may not have
dll interface
So something like
extern PGDLLIMPORT thread_local struct Port *MyProcPort;
wouldn't work (confirmed).
That might be a problem, since we now mark all global variables as
PGDLLIMPORT.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mihail Nikalayeu | 2025-11-18 22:19:00 | Re: Bug in amcheck? |
| Previous Message | Matheus Alcantara | 2025-11-18 22:13:17 | Re: postgres_fdw: Use COPY to speed up batch inserts |