Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)
Дата
Msg-id CA+TgmoaqG_z5tkxScDAn991Zh-7yzEyxEdKRF18zjXtfkQTatA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)