From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: fork/exec |
Date: | 2003-11-30 17:30:11 |
Message-ID: | 24103.1070213411@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> Would it be possible to re-jig ShmemInitStruct to not require locking
That strikes me as entirely unsafe.
Back when we actually had fork/exec for Unix, there were three shmem
segments not one. Part of the reason for this was that spinlocks
occupied their own segment, and so they could be found and accessed
without any reference to the main shmem index. (I forget what the
third segment was for, but I think it was not critical for startup.)
Probably the best way to model this now is to put a pointer (or whatever
is needed) to the LWLock array into the shmem segment header, whence
it can be grabbed without any locking. This will allow a new backend's
lock manager to be initialized immediately. Then we can safely (ie,
with locking) initialize access to the shmem index hashtable (it might
take another pointer in the segment header to find it) and then
everything else can be looked up in the index hashtable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Natoli | 2003-12-01 00:37:23 | Re: fork/exec |
Previous Message | Bruce Momjian | 2003-11-30 15:48:45 | Re: fork/exec |