Re: atomics.h may not be included from frontend code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: atomics.h may not be included from frontend code
Date
Msg-id 20180227185847.vnmu7cblwvit7qwp@alap3.anarazel.de
Whole thread Raw
In response to Re: atomics.h may not be included from frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018-02-27 13:43:23 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-02-27 10:36:01 -0500, Robert Haas wrote:
> >> However, those are presumably rare configurations that many people
> >> (including many developers) don't care about.
> 
> > I don't think that's quite true anymore. We e.g. now rely on 64bit
> > atomics being emulated on some machines, and they're unavailable on a
> > bigger number of systems than atomics proper, particularly 32bit
> > sytems.  There's also hppa, of course ;)
> 
> I had the idea that there were also still some MIPS machines out there
> with no real atomics support.  If there's not, I wouldn't complain
> hard about deciding to desupport HPPA, whenever we want to rip out
> the fallbacks.

There's definitely several machines that we currently support without
good enough atomics support. I don't *think* mips is among them, the
architectural manuals I had looked at when implementing it suggested
ll/sc type support is available everywhere.

https://wiki.postgresql.org/wiki/Atomics
lacking 32 bit atomics: armv5, sparcv8, pa-risc, m32r, i386
lacking 64 bit atomics: some ppc, armv6, i486, !gcc !msvc x86 in 32bit mode

None of these seem extremely interesting personally, but I'm way happier
to drop platforms than some others ;


> I am not sure though that we want to promise that atomics.h would work
> in arbitrary frontend environments in any case.  Those functions are
> very specifically intended to do what PG needs them to do; do we
> really want them to try to serve multiple masters?

I think if we'd allow the client to implement a locking mechanism for
the fallback implementation, there'd not be a big issue. Besides the
fallback code there's really not that much PG specificity in there...

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sigh, I broke crake again
Next
From: Robert Haas
Date:
Subject: Re: Let's remove DSM_INPL_NONE.