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)
Дата
Msg-id 1551701.1592495972@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 17, 2020 at 5:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wouldn't object to making the outer-layer macros in spin.h into static
>> inlines; as mentioned, that might have some debugging benefits.  But I
>> think messing with s_lock.h for marginal cosmetic reasons is a foolish
>> idea.  For one thing, there's no way whoever does it can verify all the
>> architecture-specific stanzas.  (I don't think we even have all of them
>> covered in the buildfarm.)

> It would be a pretty mechanical change to use a separate preprocessor
> symbol for the conditional and just define the static inline functions
> on the spot. There might be one or two goofs, but if those platforms
> are not in the buildfarm, they're either dead and they don't matter,
> or someone will tell us what we did wrong. I don't know. I don't have
> a huge desire to spend time cleaning up s_lock.h and I do think it's
> better not to churn stuff around just for the heck of it, but I'm also
> sympathetic to Andres's point that using macros everywhere is
> debugger-unfriendly.

Sure, but wouldn't making the SpinLockAcquire layer into static inlines be
sufficient to address that point, with no need to touch s_lock.h at all?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: [patch] demote
Следующее
От: Tom Lane
Дата:
Сообщение: Re: jsonpath versus NaN