Re: FlexLocks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: FlexLocks
Дата
Msg-id CA+TgmoZW0mY4HpzYS=Jw7d=YLuwi71jCHEVmyQS7Wzjr=_hvXg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FlexLocks  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: FlexLocks
Список pgsql-hackers
On Wed, Nov 16, 2011 at 11:17 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> Now maybe there is some better way to do this, but at the moment,
>> I'm not seeing it.  If we call them all LWLocks, but only some of
>> them support LWLockAcquire(), then that's going to be pretty
>> weird.
>
> Is there any way to typedef our way out of it, such that a LWLock
> *is a* FlexLock, but a FlexLock isn't a LWLock?  If we could do
> that, you couldn't use just a plain old FlexLock in LWLockAcquire(),
> but you could do the cleanups, etc., that you want.

Well, if we just say:

typedef FlexLockId LWLockId;

...that's about equivalent to the #define from the compiler's point of
view.  We could alternatively change one or the other of them to be a
struct with one member, but I think the cure might be worse than the
disease.  By my count, we are talking about saving perhaps as many as
34 lines of code changes here, and that's only if complicating the
type handling doesn't require any changes to places that are untouched
at present, which I suspect it would.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: FlexLocks
Следующее
От: Tom Lane
Дата:
Сообщение: declarations of range-vs-element <@ and @>