[HACKERS] 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 the map 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about SHM_QUEUE
ITAGAKI Takahiro [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Question about SHM_QUEUE
Tom Lane [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Question about SHM_QUEUE
ITAGAKI Takahiro wrote: Tom Lane [EMAIL PROTECTED] 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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Question about SHM_QUEUE
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
