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>
