> You have broken stuff before by rearranging the sequence of operations...
Ah, yeah, well, FWIW, if that is the only thing that gets broken in the process of making this port, I'll be more than satisfied. Will that be held against me forever? > what exactly have you got in mind here? Moving InitShmemIndex into InitShmemAllocation. I'd like to make this the first call, inside the context of ShmemBootstrap = true, and insert logic to avoid SpinLock acquisition/release inside ShmemAlloc/ShmemInitStruct (when ShmemBootstrap = true). Not pretty, but I'll trade off the removal of other ugliness (like the ShmemLock/ShmemIndexLock spinlock memory allocation, which could then just use ShmemAlloc). > > ... a possible solution to a Win32 shmem/semaphore bootstrap > > problem (postgres semaphores under Win32 uses ShmemIndex which uses > > spinlocks which use shared memory which use semaphores which ...). > The correct solution to that seems to lie elsewhere, ie, not use semaphores for spinlocks. Just working with what we've already got. There seems to be very usable code in src/backend/port/win32/sema.c, which gets invoked as Win32 does not have spin-locks, but unfortunately relies on ShmemInitStruct. If you've got a shorter path in mind, I'm all ears. Cheers, 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> ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
