> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Agreed. We have to pass the shared memory address, but the
> rest should
> > be registered in shared memory somewhere and we can initialize those
> > values. The old code used to point _using_ those memory
> pointers, but I
> > don't think that is necessary --- in fork/exec mode, we can just use
> > share memory to initialize the pointers properly.
> Yeah. It might be useful to extend the shmem segment header (which at
> the moment is mostly just for identification) to hold one or two
> critical addresses, such as the address of the LWLock array. But the
> index map used to work for this back when we had fork/exec in the Unix
> implementation, so it should be possible to make it work again without
> undue amounts of pain.
> regards, tom lane
One slight circular problem with that. Currently, ShmemInitStruct waits on a
lock (ShmemIndexLock), locks require the MyProc structure (set by
InitProcess), and InitProcess needs access to... a bunch of shared memory
Would it be possible to re-jig ShmemInitStruct to not require locking (at
least for backend initialization)? Other ideas?
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
pgsql-hackers-win32 by date
|Next:||From: Claudio Natoli||Date: 2003-11-30 13:11:54|
|Subject: Re: fork/exec|
|Previous:||From: Bruce Momjian||Date: 2003-11-30 03:31:03|
|Subject: Re: SRA Win32 sync() code|