Re: fork/exec

Поиск
Список
Период
Сортировка
Искать
От
Claudio Natoli
Тема
Re: fork/exec
Дата
Msg-id
A02DEC4D1073D611BAE8525405FCCE2B028053@harris.memetrics.local
Список
Дерево обсуждения
Re: fork/exec Claudio Natoli <claudio.natoli@memetrics.com>
Re: fork/exec Bruce Momjian <pgman@candle.pha.pa.us>
Re: fork/exec Tom Lane <tgl@sss.pgh.pa.us>

> Bruce Momjian  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


Understood. 

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
structs :-)

Would it be possible to re-jig ShmemInitStruct to not require locking (at
least for backend initialization)? Other ideas?

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/em
ailpolicy.html
В списке pgsql-hackers-win32 по дате отправления
От: Bruce Momjian
Дата:
Сообщение: Re: SRA Win32 sync() code
От: Claudio Natoli
Дата:
Сообщение: Re: fork/exec
FAQ