Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)
Date
Msg-id CA+TgmoaqG_z5tkxScDAn991Zh-7yzEyxEdKRF18zjXtfkQTatA@mail.gmail.com
Whole thread Raw
In response to Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jun 17, 2020 at 3:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > This seems like it's straight out of the department of pointless
> > abstraction layers. Maybe we should remove all of the S_WHATEVER()
> > stuff and just define SpinLockAcquire() where we currently define
> > S_LOCK(), SpinLockRelease() where we currently define S_UNLOCK(), etc.
> > And, as you say, make them static inline functions while we're at it.
>
> The macros are kind of necessary unless you want to make s_lock.h
> a bunch messier, because we use #ifdef tests on them.

Where?

> We could get rid of the double layer of macros, sure, but TBH that
> sounds like change for the sake of change rather than a useful
> improvement.

Really? Multiple layers of macros seem like they pretty clearly make
the source code harder to understand. There are plenty of places where
such devices are necessary for one reason or another, but it doesn't
seem like something we ought to keep around for no reason.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)
Next
From: Tom Lane
Date:
Subject: Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)