Tom Lane writes: > [cvs is your friend...] It appears to have been added as part of the > MinGW porting work last May. I don't have much faith in it; as far as > I heard the MinGW port never got further than making the client-side > code work, and so this file has no real-world testing.
FWIW, I've done a code walk-through, and it looks ok (lack of real-world testing notwithstanding), and actually does use the Win32 sema set. The only real problem is that it calls ShmemInitStruct in semget, which ultimately gets us into bootstrap hell (without native spinlocks, at least). Also, as far as using it in the "hardware independent" version of spin-locks go, it makes kernel calls, which, as spin.c comments: "is too slow to be very useful". > > No chance on getting the Shmem bootrap rearrangement past you, as > > described in my earlier mail? > > I didn't say no chance, I was just questioning the reason. This was my only reasoning (with the small benefit that it rids us of the ShmemLock/ShmemIndexLock creation ugliness, for equivalent ShmemBootstrap ugliness). Ok, I think having a native win32 spin-lock implementation (say, based on InterlockedCompareExchange?) is the minimal impact answer. I'll work on producing that. 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
