Re: pg_threads.h take II

On Thu, Nov 5, 2026 at 12:19 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> On 31.07.26 04:18, Thomas Munro wrote:
> > I decided to split the API patch into two parts, to highlight
> > something interesting:
> >
> > v3-0002 pg_threads.h with support for <pthread.h> or <threads.h>
> > v3-0003 adds <windows.h> option for native Windows API
> >
> > If we are ready to make <threads.h> a hard requirement for Visual
> > Studio builds, and willing to use the <pthread.h> implementation that
> > ships with MinGW, then we don't actually need v3-0003. That means
> > that we're left with almost no code, mostly just renaming wrappers and
> > comments.
> >
> > CI passes with or without v3-0003.
> >
> > I also fixed the commit message for v3-0006 which I'd failed to update
> > (I abandoned my thread-exit invention and just went with tss_t in the
> > end). No other changes from v2.
>
> What is the status of this patch set?
>
> I note that some of the patches had already been reviewed earlier in the
> thread as good for commit, but I don't think that was done. Have the
> newer patch set versions invalidated these reviews?

Later versions are similar to what was reviewed, but much more
polished and fleshed out:

* covered the full C11 <threads.h> API
* ditched my made-up at-exit thing (early on I had misdiagnosed why
early attempts to implement pg_tss_t on Win32 APIs crashed and
burned... it turned out I was just confused by pre-existing bugs in
ECPG, see patch 0001)
* split the per-system implementations into _impl.h headers, using
some macros to reduce boiler-plate duplication and mistakes
* added a third implementation that just points to a system
<threads.h> implementation, which we might want to consider
"conformance demonstrating" developer-only build option, or we might
want to decide now or later to use for Windows/MSVC
* split the interface into pg_threads.h and pg_threads_ext.h to
clearly separate the additions to <threads.h> that I think we need
* did more work on determining and documenting exactly why and when
it's safe for pg_threads_ext.h to define static initialisers for each
of the three implementations
* provided a way to get at underlying implementation errors based on
Heikki's comments, see pg_thrd_error_string_with_detail()
* researched the ID vs handle schism that Bryan highlighted on
Windows, and what user-visible impedance mismatch results, what VS's
own <threads.h> does about that, what we should do about it, see
PG_THRDS_CURRENT_NOT_{JOINABLE,DETACHABLE} and
PG_THRD_CURRENT_CONFORMING (ie I showed how to work around it, at a
small cost to pg_thrd_create(), but also that VS's <threads.h> doesn't
bother to do that and instead just fails to conform to C11)
* researched the MinGW situation and realised that although it doesn't
offer <threads.h> yet, its <pthreads.h> works just fine (relevant
because its lack of <threads.h> would otherwise have cut off the
option of requiring <threads.h> on Windows)

Does anyone want to opine on whether we want v3-0003 or not? If we
don't commit v3-0003, we have onto two implementations and we get:

* Unixen, Windows/MinGW = pthread.h
* Windows/MSVS = threads.h
* Most Unixen can also be told to use threads.h for
developer/conformance testing

If we do commit v3-0003, we have three implementations and we get:

* Unixen, Windows/MinGW = pthread.h
* Windows/MSVS = windows.h
* Most Unixen + Windows/VS can also be told to use threads.h for
developer/conformance testing

> I'm looking at some other patch sets that are fiddling with threads and
> the API layers, and I'm wondering if it's worth proceeding with those,
> or rather focus on getting this patch set done and then rebase those
> other ones on top of this new API.

I still need to think about Jakub's recent feedback, but once I've
done that, and once we have a decision on v3-0003, I think something
like 0001-0008 should be about ready to commit?

Then looking at the higher numbered patches, I wonder if anyone has
any comments on these ideas for (IMHO) improving some of the nastier
cleanup programs we deal with in frontend programs on ^C:

* v3-0010 is way for frontend programs to run their cleanup handler in
a thread, ie more like Windows
* v3-0011 is a way for such a handler to clean up a set of connections

I need to compare Bryan's work on frontend thread architecture and see
if my (competing) proposals for the same programs are redundant
(assuming he's rebased on pg_threads.h that we hopefully commit soon),
and/or whether my 0010/0011 stuff is useful/relevant or he had better
idea, etc...