Re: Question about SHM_QUEUE
От
Tom Lane
Тема
Re: Question about SHM_QUEUE
Дата
Msg-id
13869.1176300254@sss.pgh.pa.us
Ответ на
Re: Question about SHM_QUEUE (Alvaro Herrera)
Список
Дерево обсуждения
Question about SHM_QUEUE ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Question about SHM_QUEUE Tom Lane <tgl@sss.pgh.pa.us>
Re: Question about SHM_QUEUE ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Re: Question about SHM_QUEUE Alvaro Herrera <alvherre@commandprompt.com>
Re: Question about SHM_QUEUE Tom Lane <tgl@sss.pgh.pa.us>
Alvaro Herrera 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
В списке pgsql-hackers по дате отправления