Обсуждение: Question about SHM_QUEUE
Hello, I have a question about SHM_QUEUE. Why do we need this component? We've already made some modules under the assumption that the base offset of shared memory is mapped to the same address for all processes. See comment in freespace.h: * Note: we handle pointers to these items as pointers, not as SHMEM_OFFSETs.* This assumes that all processes accessing themap will have the shared* memory segment mapped at the same place in their address space. Then, can we replace SHM_QUEUE by a pointer-based double-linked list? It will be an "intrusive" version of Dllist. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> I have a question about SHM_QUEUE. Why do we need this component?
It's a hangover from Berkeley days that no one has felt a need to remove
yet. The convention back then was that shared memory might be mapped to
different addresses in different processes. We've since adopted the
assumption that everyone will see the same addresses, but we have not
made any attempt to eradicate the old approach everywhere.
> Then, can we replace SHM_QUEUE by a pointer-based double-linked list?
> It will be an "intrusive" version of Dllist.
What exactly will you gain by it? I'm not inclined to fool with that
code for trivial reasons ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I have a question about SHM_QUEUE. Why do we need this component? > It's a hangover from Berkeley days that no one has felt a need to remove yet. > > > Then, can we replace SHM_QUEUE by a pointer-based double-linked list? > What exactly will you gain by it? I'm not inclined to fool with that > code for trivial reasons ... Hmmm, my next question is whether we should use SHM_QUEUE or not in new modules. The point deluded me when I wrote DSM and I wondered the autovacuum-multiworkers patch uses SHM_QUEUE. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
ITAGAKI Takahiro wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > I have a question about SHM_QUEUE. Why do we need this component? > > It's a hangover from Berkeley days that no one has felt a need to remove yet. > > > > > Then, can we replace SHM_QUEUE by a pointer-based double-linked list? > > What exactly will you gain by it? I'm not inclined to fool with that > > code for trivial reasons ... > > Hmmm, my next question is whether we should use SHM_QUEUE or not in > new modules. The point deluded me when I wrote DSM and I wondered > the autovacuum-multiworkers patch uses SHM_QUEUE. Good question. I used SHM_QUEUE because I just believed the comments that said that ShmemBase would be different on each process, and so using plain pointers would not work. I admit I didn't even try. So if the list can be implemented in a different way, I have no problem with changing that code -- but then, if there's no practical problem with it I feel uninclined to continue messing with the patch until it's committed. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> ITAGAKI Takahiro wrote:
>> Hmmm, my next question is whether we should use SHM_QUEUE or not in
>> new modules. The point deluded me when I wrote DSM and I wondered
>> the autovacuum-multiworkers patch uses SHM_QUEUE.
> Good question. I used SHM_QUEUE because I just believed the comments
> that said that ShmemBase would be different on each process, and so
> using plain pointers would not work. I admit I didn't even try. So if
> the list can be implemented in a different way, I have no problem with
> changing that code -- but then, if there's no practical problem with it
> I feel uninclined to continue messing with the patch until it's
> committed.
The main disadvantage of converting pointers to SHMEM_OFFSETs is that
it reduces the compiler's ability to help you find mistakes (ie,
treating a pointer to X as a pointer to Y). So I'd encourage people
to use plain pointers in new code. But I don't feel a compulsion to
convert existing code. Also, in a situation where you'd be writing
"void *" (eg, a generic linked-list type...) there's just no gain in
protection anyway.
regards, tom lane