Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jun 18, 2020 at 11:59 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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?
> I mean, wouldn't you then end up with a bunch of 1-line functions
> where you can step into the function but not through whatever
> individual things it does?
Not following your point. The s_lock.h implementations tend to be either
simple C statements ("*lock = 0") or asm blocks; if you feel a need to
step through them you're going to be resorting to "si" anyway.
I think the main usefulness of doing anything here would be (a) separating
the spinlock infrastructure from callers and (b) ensuring that we have a
declared argument type, and single-evaluation semantics, for the spinlock
function parameters. Both of those are adequately addressed by fixing
spin.h, IMO anyway.
regards, tom lane
