Re: Cleaning up threading code

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up threading code
Date: 2023-07-03 08:43:14
Message-ID: 7c8fc64b-eeb3-4fac-9c83-ccb0bf246d4a@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/07/2023 10:29, Peter Eisentraut wrote:
> On 10.06.23 07:26, Andres Freund wrote:
>>> -###############################################################
>>> -# Threading
>>> -###############################################################
>>> -
>>> -# XXX: About to rely on thread safety in the autoconf build, so not worth
>>> -# implementing a fallback.
>>> -cdata.set('ENABLE_THREAD_SAFETY', 1)
>>
>> I wonder if we should just unconditionally set that in c.h or such? It'd not
>> be crazy for external projects to rely on that being set.
>
> We definitely should keep the mention in ecpg_config.h.in, since that is
> explicitly put there for client code to use. We keep HAVE_LONG_LONG_INT
> etc. there for similar reasons.

+1. Patches 1-3 look good to me, with the things Andres & Peter already
pointed out.

The docs at https://www.postgresql.org/docs/current/libpq-threading.html
needs updating. It's technically still accurate, but it ought to at
least mention that libpq on v17 and above is always thread-safe. I
propose the attached. It moves the note on "you can only use one PGConn
from one thread at a time" to the top, before the description of the
PQisthreadsafe() function.

On 10/06/2023 05:23, Thomas Munro wrote:
>
> 2. I don't like the way we have to deal with POSIX vs Windows at
> every site where we use threads, and each place has a different style
> of wrappers. I considered a few different approaches to cleaning this
> up:
>
> * provide centralised and thorough pthread emulation for Windows; I
> don't like this, I don't even like all of pthreads and there are many
> details to get lost in
> * adopt C11 <threads.h>; unfortunately it is too early, so you'd need
> to write/borrow replacements for at least 3 of our 11 target systems
> * invent our own mini-abstraction for a carefully controlled subset of stuff

Google search on "c11 threads on Windows" found some emulation wrappers:
https://github.com/jtsiomb/c11threads and
https://github.com/tinycthread/tinycthread, for example. Would either of
those work for us?

Even if we use an existing emulation wrapper, I wouldn't mind having our
own pg_* abstration on top of it, to document which subset of the POSIX
or C11 functions we actually use.

--
Heikki Linnakangas
Neon (https://neon.tech)

Attachment Content-Type Size
update-libpq-thread-safety-docs.patch text/x-patch 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-07-03 08:48:17 Re: On /*----- comments
Previous Message Peter Eisentraut 2023-07-03 08:37:43 Re: CI and test improvements