Re: Win32 Thread safetyness

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Win32 Thread safetyness
Date: 2005-08-28 18:17:49
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE0946C0@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

> The basic issue with SSL is that it wants some unique
> identifier for threads. They really should have defined the
> function to take pthread_t rather than unsigned long because
> pthreads doesn't really give us a useful way to get an

They absolutely should not have done that. That would've locked them to
pthreads and not other type of thread implementation.

> How is this pthread_self() call working on Win32 now? Is
> pthreads a requirement for libpq threading on Win32? I
> didn't think it was.

The version that's in CVS now uses our own pthreads wrapper, so it's
definitly not a requirement:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/pt
hread-win32.c?rev=1.8

Note that we are not safe per these requirements - pthread_self()
returns GetCurrentThread(), which in turn returns a *pseudo handle that
has the same value in every thread*.
We need to be using GetCurrentThreadId() (it's a DWORD
GetCurrentThreadId(void), so it should be a simple replacement in the
file). Please make that change (I don't think you need a patch for this,
right?) regardless, that's a clear bug in our current implementation.
Should be backpatched as well. (No I haven't tested it, so pleas emake
sure it compiles :P) If you need a patch for it let me know.

> As far as ecpg is concerned, I think the right plan is to use
> Win32 threads for libpq, but to use pthreads in ecpg.
> However, will Win32 threads still work in ecpg if we use
> pthreads to do the locking? Maybe we have to force ecpg
> users to use pthreads on Win32.

If it works, that's definitly the best. Forcing pthreads on every user
will be almost equal to saying we're not thread-safe on win32. While it
would still be bad for ecpg users, there aren't as many of those as
there are libpq users :-)

> Also, there doesn't seem to be a good way for users to know
> if libpq or ecpg was compiled to be thread-safe.

Right. A runtime function for this might be a good thing? Like "bool
PQisThreadSafe()" or such?

//Magnus

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-08-28 18:53:50 Re: Win32 Thread safetyness
Previous Message Tom Lane 2005-08-28 18:04:43 Re: Segfault Exiting psql