Re: Compiling libpq with VisualC

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
#include <stdio.h>
#include <stdlib.h>


int g_mutex;


extern "C" int main(void) {
    printf("in main. Value now %d.\n", g_mutex);
}

class init_me
{
public:
        init_me::init_me(void)
    {
        g_mutex = 99; /* CreateMutex(), or whatever. */
    }
};

static class init_me instance_one;