[PATCH] s_lock support for win32

The win32 port doesn't have a native user space spinlock
implementation yet.

It does when compiled with MingW.

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>

Claudio Natoli <claudio.natoli@memetrics.com> writes:

The win32 port doesn't have a native user space spinlock
implementation yet.

It does when compiled with MingW.

Are we intending to support any other compilers/build environments
than that one?

Offhand I would prefer to see us using the existing i386 spinlock
code under Windows, because that's already tested and known to work.
However I can see that this would not fly when using a non-gcc
compiler ...

regards, tom lane

Tom Lane writes:

Claudio Natoli <claudio.natoli@memetrics.com> writes:

The win32 port doesn't have a native user space spinlock
implementation yet.

It does when compiled with MingW.

Are we intending to support any other compilers/build environments
than that one?

Not currently; at least not for the backend, as psql/libpq etc continue to
also be supported under VC++.

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>

Because we don't support non-gcc Win32 builds of the backend, adding
this patch doesn't make sense. If we ever start to support non-gcc
Win32 backends we can add this.

---------------------------------------------------------------------------

Manfred Spraul wrote:

Hi,

The win32 port doesn't have a native user space spinlock implementation
yet. Attached is an untested patch - could someone test it? I don't have
Visual C++.

--
Manfred

!DSPAM:40e2f9cf213266268715824!

Index: src/include/storage/s_lock.h
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/include/storage/s_lock.h,v
retrieving revision 1.126
diff -c -r1.126 s_lock.h
*** src/include/storage/s_lock.h	19 Jun 2004 23:02:32 -0000	1.126
--- src/include/storage/s_lock.h	30 Jun 2004 17:14:08 -0000
***************
*** 648,653 ****
--- 648,661 ----

#endif /* !defined(HAS_TEST_AND_SET) */

+ #if defined(WIN32)
+ #define HAS_TEST_AND_SET
+ 
+ typedef long slock_t;
+ 
+ #define TAS(lock)	(InterlockedExchange(lock, 1))
+ #define S_UNLOCK(lock)	(InterlockedExchange(lock, 0))
+ #endif

/* Blow up if we didn't have any way to do spinlocks */
#ifndef HAS_TEST_AND_SET

!DSPAM:40e2f9cf213266268715824!

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

!DSPAM:40e2f9cf213266268715824!

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

Bruce Momjian wrote:

Because we don't support non-gcc Win32 builds of the backend, adding
this patch doesn't make sense. If we ever start to support non-gcc
Win32 backends we can add this.

Ok. I wasn't aware that the backend is gcc-only.
But what about my libpq patch? Races in the library startup just ask for
corruptions.

--
Manfred

Manfred Spraul wrote:

Bruce Momjian wrote:

Because we don't support non-gcc Win32 builds of the backend, adding
this patch doesn't make sense. If we ever start to support non-gcc
Win32 backends we can add this.

Ok. I wasn't aware that the backend is gcc-only.
But what about my libpq patch? Races in the library startup just ask for
corruptions.

The backend is gcc (MinGW) only on Win32. We support non-gcc, but not
on Win32.

Yes, I saw the thread locking patch and will be applying that soon.

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Manfred Spraul wrote:

But what about my libpq patch? Races in the library startup just ask for
corruptions.

Yes, I saw the thread locking patch and will be applying that soon.

Has this been agreed to by the win32-hackers list? My recollection is
that there was still considerable disagreement about the appropriate
way to deal with this issue.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Manfred Spraul wrote:

But what about my libpq patch? Races in the library startup just ask for
corruptions.

Yes, I saw the thread locking patch and will be applying that soon.

Has this been agreed to by the win32-hackers list? My recollection is
that there was still considerable disagreement about the appropriate
way to deal with this issue.

Yes, we resolved that by doing proper locking (3 weeks ago), but it
turns out the code wasn't 100% proper and this fixes it.

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