Re: Win32 Thread safetyness

Magnus Hagander wrote:
> > 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.

True.

> > 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*.

Ewe.

> 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.

Change made.  Thanks.  I didn't check the compile but I am sure someone
will and report back a failure.  :-)

> > 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?

Yes, and a flag to ecpg.  Added to TODO:
* Add function to return the thread safety status of libpq and ecpg


--  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,
Pennsylvania19073