Re: Cleaning up threading code

On Sun, Apr 14, 2024 at 3:16 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> So I'll go ahead and add the storage class to the next version, and
> contemplate a couple of different options for the tss stuff, including
> perhaps leaving it out if that seems doable.

Here is a new attempt at pg_threads.h. Still work in progress, but
passing tests, with storage class and working TSS, showing various
users.

I eventually understood first that my TSS destructor problems on
Windows came from mismatched calling conventions, and that you can't
really trampoline your way around that, at least not without doing
some pretty unreasonable things, and that is why nobody can emulate
either tss_create() or pthread_key_create() directly with Windows'
FlsAlloc(), so everybody who tries finishes up building their own
infrastructure to track destructors, or in ECPG's case just leaks all
the memory instead.

Here's the simplest implementation I could come up with so far. I
don't have Windows so I made it possible to use emulated TSS
destructors on my local machine with a special macro for testing, and
then argued with CI for a while until the other machines agreed.
Otherwise, it's all a fairly thin wrapper and hopefully not suprising.

In one place, an ECPG thread-local variable has no destructor, so we
can use it as the first example of the new pg_thread_local storage
class.

One thing this would need to be complete, at least the way I've
implemented it, is memory barriers, for non-TSO hardware, which would
require lifting the ban on atomics.h in frontend code, or at least
parts of it. Only 64 bit emulation is actually tied to the backend
now (because it calls spinlock stuff, that itself is backend-only, but
also it doesn't actually need to be either). Or maybe I can figure
out a different scheme that doesn't need that. Or something...

WIP patch attached.