Re: fork/exec
От | Claudio Natoli |
---|---|
Тема | Re: fork/exec |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B028056@harris.memetrics.local обсуждение исходный текст |
Ответы |
Re: fork/exec
|
Список | pgsql-hackers-win32 |
> Claudio Natoli <claudio.natoli@memetrics.com> writes: > > Would it be possible to re-jig ShmemInitStruct to not > require locking > > That strikes me as entirely unsafe. Well, an implicit assumption in asking if it was "possible" was if it was possible safely... > 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. Agreed. But I think we'd also need to pass ProcGlobal and ProcStructLock, and move the InitProcess call to be made earlier (so that the MyProc structure is initialized, which is a requirement for locking). Right? Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
В списке pgsql-hackers-win32 по дате отправления: