Обсуждение: don't use MAKE_PTR/OFFSET for shmem pointers

Поиск
Список
Период
Сортировка

don't use MAKE_PTR/OFFSET for shmem pointers

От
Kris Jurka
Дата:
Since we require every process to map the shared memory region to the same 
address, we don't need the MAKE_PTR/OFFSET code that was needed when that
was not the case.  This patch makes shared memory pointers just like 
regular pointers.

http://archives.postgresql.org/pgsql-general/2007-08/msg01510.php

Kris Jurka

Re: don't use MAKE_PTR/OFFSET for shmem pointers

От
Tom Lane
Дата:
Kris Jurka <books@ejurka.com> writes:
> Since we require every process to map the shared memory region to the same 
> address, we don't need the MAKE_PTR/OFFSET code that was needed when that
> was not the case.  This patch makes shared memory pointers just like 
> regular pointers.

Applied with minor editorialization --- mainly, I converted a couple of
"void *" pointer declarations to more specific types, since it seems to
me the main point of this is to not use nonspecific pointers
unnecessarily.
        regards, tom lane


Re: don't use MAKE_PTR/OFFSET for shmem pointers

От
Alvaro Herrera
Дата:
Tom Lane wrote:
> Kris Jurka <books@ejurka.com> writes:
> > Since we require every process to map the shared memory region to the same 
> > address, we don't need the MAKE_PTR/OFFSET code that was needed when that
> > was not the case.  This patch makes shared memory pointers just like 
> > regular pointers.
> 
> Applied with minor editorialization --- mainly, I converted a couple of
> "void *" pointer declarations to more specific types, since it seems to
> me the main point of this is to not use nonspecific pointers
> unnecessarily.

We now have two very similar doubly-linked list implementations.  Should
we take one of them out?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


Re: don't use MAKE_PTR/OFFSET for shmem pointers

От
Tom Lane
Дата:
Alvaro Herrera <alvherre@commandprompt.com> writes:
> We now have two very similar doubly-linked list implementations.  Should
> we take one of them out?

If you're thinking of dllist, it has considerably different implementation
assumptions.
        regards, tom lane