

Tom Lane writes:
> > 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.
>
> Win32 certainly has spinlocks; it does not run on any hardware for which
> we don't have spinlock assembler.  For that matter, doesn't it have
> POSIX-compatible semaphores?  I'm not sure there's any need for
> src/backend/port/win32/sema.c at all.

["as Win32 does not have" should have been read as "as Postgres Win32 does
not have"]

I'll have a look at how we could fit in spinlock code for Win32, or at
least, using the Win32 semaphores. (Do you have any idea on the historical
context of this code? I wondered as to, if we have no win32 port, why there
would be a seemingly good-to-go sema replacement?)

No chance on getting the Shmem bootrap rearrangement past you, as described
in my earlier mail? IMNSHO, it is not entirely without merit.

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>

Tue, 13 Jan 2004 16:15:09 +1100
Claudio Natoli <claudio.natoli@memetrics.com>
Re: LWLock/ShmemIndex startup question 
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Tom Lane writes:
>> I'm not sure there's any need for
>> src/backend/port/win32/sema.c at all.

> (Do you have any idea on the historical
> context of this code? I wondered as to, if we have no win32 port, why there
> would be a seemingly good-to-go sema replacement?)

[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.

> 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.  We don't
need a slavish implementation of SysV semaphores.  What we need is
something implementing the API defined by src/include/storage/pg_sema.h
for which we presently have two implementations:
	src/backend/port/posix_sema.c
	src/backend/port/sysv_sema.c
(actually three implementations if you count named and unnamed POSIX
semaphores as different, which you very well could).  I'd be inclined
to think that something using Windows-native semaphore primitives to
implement this API is the way to go.

			regards, tom lane

Tue, 13 Jan 2004 00:44:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLock/ShmemIndex startup question 
Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Tom Lane writes:
> >> I'm not sure there's any need for
> >> src/backend/port/win32/sema.c at all.
> 
> > (Do you have any idea on the historical
> > context of this code? I wondered as to, if we have no win32 port, why there
> > would be a seemingly good-to-go sema replacement?)
> 
> [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.

Right, that is from PeerDirect's Win32 port, with a little cleanup.  It
should work fine, or we can wack it around.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 22 Jan 2004 23:55:32 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: LWLock/ShmemIndex startup question