Re: FlexLocks

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: FlexLocks
Дата
Msg-id 4EC381B50200002500043031@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: FlexLocks  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: FlexLocks  (Robert Haas <robertmhaas@gmail.com>)
Re: FlexLocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> wrote:
> I just don't see the reason to do a global search and replace on
> the lwlock name
I was going to review further before commenting on that, but since
it has now come up -- it seems odd that a source file which uses
only LW locks needs to change so much for the FlexLock
implementation.  I'm not sure source code which uses the next layer
up from FlexLock should need to be aware of it quite so much.  I
assume that this was done to avoid adding a layer to some code where
it could cause an unnecessary performance hit, but maybe it would be
worth just wrapping with a macro to isolate the levels where that's
all it takes.
For example, if these two macros were defined, predicate.c wouldn't
have needed any modifications, and I suspect that is true of many
other files (although possibly needing a few other macros):
#define LWLockId FlexLockId
#define LWLockHeldByMe(lock) FlexLockHeldByMe(lock)
Particularly with the function call it seems like it's a mistake to
assume that test will always be the same between LW locks and flex
locks.  There may be a better way to do it than the above, but I
think a worthy goal would be to impose zero source code changes on
code which continues to use "traditional" lightweight locks.
-Kevin


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

Предыдущее
От: Greg Smith
Дата:
Сообщение: CommitFest 2011-11 Started
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Core Extensions relocation