On Wed, Nov 16, 2011 at 3:41 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Now, you're always going to use
> LWLockAcquire() and LWLockRelease() to acquire and release an LWLock,
> but a FlexLockId isn't guaranteed to be an LWLockId - any given value
> might also refer to a FlexLock of some other type. If we let everyone
> continue to refer to those things as LWLockIds, then it seems like
> only a matter of time before someone has a variable that's declared as
> LWLockId but actually doesn't refer to an LWLock at all. I think it's
> better to bite the bullet and do the renaming up front, rather than
> having to think about it every time you modify some code that uses
> LWLockId or LWLockHeldByMe and say to yourself, "oh, wait a minute, is
> this really guaranteed to be an LWLock?"
But that's an advantage to having a distinct API layer for LWLock
instead of having callers directly call FlexLock methods. The LWLock
macros can AssertMacro that the lockid they were passed are actually
LWLocks and not some other type of lock. That would require assigning
FlexLockIds that are recognizably LWLocks but that's not implausible
is it?
--
greg