> 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