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.

#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
		g_mutex = 99; /* CreateMutex(), or whatever. */

static class init_me instance_one;

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to