On Fri, 2004-01-23 at 00:21, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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 mi
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 kn
Bruce Momjian <[EMAIL PROTECTED]> 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
Claudio Natoli wrote:
>
>
> 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 fil
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> 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
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> 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
> > woul
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 g
> 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
Yes, I'm working with MingW.
> If anyone kno
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> 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 o
Manfred Spraul <[EMAIL PROTECTED]> 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 o
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
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> 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
Claudio Natoli <[EMAIL PROTECTED]> 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. Whi
Claudio Natoli <[EMAIL PROTECTED]> writes:
> 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 h
> 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?
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,
Claudio Natoli <[EMAIL PROTECTED]> 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
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
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> 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
>
> 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
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Are these comments still true? Specifically, is it necessary to call
> CreateLWLocks before InitShmemIndex? I think it used to be, but then the
> ShmemIndexLock got made into a separate spinlock in its own right.
I think the only dependency was that Shm
In CreateSharedMemoryAndSemaphores, there is the following comment, just
before CreateLWLocks():
/*
* Now initialize LWLocks, which do shared memory allocation and are
* needed for InitShmemIndex.
*/
Also, in InitShmemAllocation, there is:
/* ShmemInde
22 matches
Mail list logo
