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

Or, maybe we'll just use the tas() implementation that already exists for
__i386__/__x86_64__ in s_lock.h. How did I miss that?

Move along. Nothing to see here.

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 20:44:11 +1100
Claudio Natoli <claudio.natoli@memetrics.com>
Re: LWLock/ShmemIndex startup question 
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Or, maybe we'll just use the tas() implementation that already exists for
> __i386__/__x86_64__ in s_lock.h. How did I miss that?
> Move along. Nothing to see here.

Actually, I was expecting you to complain that the s_lock.h coding is
gcc-specific.  Which compilers do we need to support on Windows?

We might have to fall back to something comparable to the CVS-tip s_lock
support for hppa: inline assembler in s_lock.h for gcc, and a separate
assembly source file for use with vendor compiler(s).

			regards, tom lane

Tue, 13 Jan 2004 09:57:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLock/ShmemIndex startup question 
Tom Lane wrote:

>Claudio Natoli <claudio.natoli@memetrics.com> writes:
>  
>
>>Or, maybe we'll just use the tas() implementation that already exists for
>>__i386__/__x86_64__ in s_lock.h. How did I miss that?
>>Move along. Nothing to see here.
>>    
>>
>
>Actually, I was expecting you to complain that the s_lock.h coding is
>gcc-specific.  Which compilers do we need to support on Windows?
>  
>
I think intel's compiler supports the gcc syntax. At least the Linux 
version can compile the Linux kernel.
MSVC has it's own syntax that is very primitive, and AFAIK not supported 
by the 64-bit windows versions. The AMD64 version definitively doesn't 
support inline assembly at all.

What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
sizeof(void*) is 8.

--
    Manfred




Tue, 13 Jan 2004 17:38:51 +0100
Manfred Spraul <manfred@colorfullife.com>
Re: LWLock/ShmemIndex startup question
Manfred Spraul <manfred@colorfullife.com> writes:
> What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
> sizeof(void*) is 8.

If you can tell me what type Datum should be (unsigned long long
maybe?), we could probably handle that.  It was a pretty brain-dead
combination of choices on Microsoft's part though ... offhand I can
think of no other platform where pointer and long are not the same
size.  There are probably a few other places besides the Datum typedef
that will need adjustment for this, but I can't think of any showstoppers.

			regards, tom lane

Tue, 13 Jan 2004 11:47:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLock/ShmemIndex startup question 
Tom Lane wrote:

>Manfred Spraul <manfred@colorfullife.com> writes:
>  
>
>>What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
>>sizeof(void*) is 8.
>>    
>>
>
>If you can tell me what type Datum should be (unsigned long long
>maybe?), we could probably handle that.
>
Probably uintptr_t: That's the official C99 integer type for storing 
pointers. I'm not sure if it's guaranteed to be wide enough for 
ULONG_MAX (or only UINT_MAX).

--
    Manfred


Tue, 13 Jan 2004 18:08:27 +0100
Manfred Spraul <manfred@colorfullife.com>
Re: LWLock/ShmemIndex startup question
Tom Lane said:
>
> Actually, I was expecting you to complain that the s_lock.h coding is
> gcc-specific.  Which compilers do we need to support on Windows?
>

AFAIK the only target build environment for Windows right now is MinGW/gcc

If anyone knows how to get the M$ compilers to work nicely with our build
system that might be interesting, but probably at a later stage.

cheers

andrew



Tue, 13 Jan 2004 12:37:21 -0500 (EST)
"Andrew Dunstan" <andrew@dunslane.net>
Re: LWLock/ShmemIndex startup question
Andrew Dunstan wrote:
> Tom Lane said:
> >
> > Actually, I was expecting you to complain that the s_lock.h coding is
> > gcc-specific.  Which compilers do we need to support on Windows?
> >
> 
> AFAIK the only target build environment for Windows right now is MinGW/gcc
> 
> If anyone knows how to get the M$ compilers to work nicely with our build
> system that might be interesting, but probably at a later stage.

MS C compiler usage would require gmake and a whole host of other stuff
that doesn't seem worth doing.

-- 
  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:54:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: LWLock/ShmemIndex startup question
Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Or, maybe we'll just use the tas() implementation that already exists for
> > __i386__/__x86_64__ in s_lock.h. How did I miss that?
> > Move along. Nothing to see here.
> 
> Actually, I was expecting you to complain that the s_lock.h coding is
> gcc-specific.  Which compilers do we need to support on Windows?
> 
> We might have to fall back to something comparable to the CVS-tip s_lock
> support for hppa: inline assembler in s_lock.h for gcc, and a separate
> assembly source file for use with vendor compiler(s).

MinGW only uses gcc so we are OK there.

-- 
  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:56:08 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: LWLock/ShmemIndex startup question
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Andrew Dunstan wrote:
>> AFAIK the only target build environment for Windows right now is MinGW/gcc
>> 
>> If anyone knows how to get the M$ compilers to work nicely with our build
>> system that might be interesting, but probably at a later stage.

> MS C compiler usage would require gmake and a whole host of other stuff
> that doesn't seem worth doing.

Um, good point.  Porting our Makefiles to anything but gmake seems
completely out of the question.  So unless someone has a Windows build
environment that has gmake but not gcc, this is moot.

			regards, tom lane

Fri, 23 Jan 2004 00:21:25 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLock/ShmemIndex startup question 


Bruce Momjian wrote:

>Andrew Dunstan wrote:
>  
>
>>Tom Lane said:
>>    
>>
>>>Actually, I was expecting you to complain that the s_lock.h coding is
>>>gcc-specific.  Which compilers do we need to support on Windows?
>>>
>>>      
>>>
>>AFAIK the only target build environment for Windows right now is MinGW/gcc
>>
>>If anyone knows how to get the M$ compilers to work nicely with our build
>>system that might be interesting, but probably at a later stage.
>>    
>>
>
>MS C compiler usage would require gmake and a whole host of other stuff
>that doesn't seem worth doing.
>  
>

That's why I phrased the suggestion rather tentatively :-)

cheers

andrew


Fri, 23 Jan 2004 16:37:50 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: LWLock/ShmemIndex startup question
On Fri, 2004-01-23 at 00:21, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Andrew Dunstan wrote:
> >> AFAIK the only target build environment for Windows right now is MinGW/gcc
> >> 
> >> If anyone knows how to get the M$ compilers to work nicely with our build
> >> system that might be interesting, but probably at a later stage.
> 
> > MS C compiler usage would require gmake and a whole host of other stuff
> > that doesn't seem worth doing.
> 
> Um, good point.  Porting our Makefiles to anything but gmake seems
> completely out of the question.  So unless someone has a Windows build
> environment that has gmake but not gcc, this is moot.
> 

Tom, check out
http://archives.postgresql.org/pgsql-ports/2004-01/msg00017.php

Looking at the interix website, they seem to have gmake but no gcc,
which seems to fit into your scenario above. Incedentally they do 
distribute a compiled PostgreSQL with their packages, though it's based
on 7.2 according to the author.  

Robert Treat 
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


27 Jan 2004 08:10:32 -0500
Robert Treat <xzilla@users.sourceforge.net>
Re: LWLock/ShmemIndex startup question