![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
The win32 port doesn't have a native user space spinlock implementation yet. |
#3
| |||
| |||
|
|
The win32 port doesn't have a native user space spinlock implementation yet. It does when compiled with MingW. |
#4
| |||
| |||
|
|
Claudio Natoli <claudio.natoli (AT) memetrics (DOT) 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? |
#5
| |||
| |||
|
|
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! |
#6
| |||
| |||
|
|
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. |
#7
| |||
| |||
|
|
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. |
#8
| |||
| |||
|
|
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. |
#9
| |||
| |||
|
|
Bruce Momjian <pgman (AT) candle (DOT) 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. |
![]() |
| Thread Tools | |
| Display Modes | |
| |