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 | 1470893.1592429348@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)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jun 17, 2020 at 3:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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? See the "Default Definitions", down near the end. >> 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. 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.) regards, tom lane
В списке pgsql-hackers по дате отправления: