Can you put that in the new pthread file that needs to be added for Win32?
---------------------------------------------------------------------------
Manfred Spraul wrote:
> Andreas Pflug wrote:
>
> > Bruce Momjian wrote:
> >
> >>
> >>
> >> Agreed. My pthread book says pthread_mutex_init() should be called only
> >> once, and we have to guarantee that. If the Windows implentation allows
> >> it to be called multiple times, just create a function to be called only
> >> by Win32 that does that and leave the Unix safe.
> >>
> >>
> >>
> > Ok, so here's the win32 workaround with the unix stuff left untouched.
> > There's no memory interlocking api in win32 that wouldn't need some
> > initializing api call itself, so we'd have to go for assembly level
> > test-and-set code.
>
> Wrong. There are portable test-and-set functions in the Win32 SDK: for
> example InterlockedCompareExchange. They operate on ints and do not need
> initialization.
>
> > or introduce a mandatory global libpq initializing api.
>
> There is a third option: Add one C++ file and use the constructor to
> initialize the mutex. VisualC is always a C++ compiler, thus C++ support
> shouldn't be an issue. I've attached an example app.
>
> > Considering the probably quite low usage of kerberos/ssl together with
> > threads under win32, and the very low probability of two
> > threads/processors (!) trying to initiate a connection at the same
> > time, it doesn't seem to be worth the compiler hassle with assembly
> > inline.
> >
> This argument is insane: Given enough installations, even a very low
> probability will cause failures.
>
> But this is a minor point, I think the patch should go in and I'll write
> with a proposal to close the race, either based on
> InterlockedCompareExchange or on a C++ file.
>
> --
> Manfred
--
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
