Re: Win32 Thread safetyness

Dave Page wrote:
> > So, we might be able to get away without this on Win32, or perhaps the
> > pthread_self().p is a valid unique identifier for Win32 threads and
> > pthreads.
> 
> Right.
> 
> > 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.
> 
> Libpq can use our existing minimal implementation of pthreads (this is
> how it currently works in CVS). The thread test program needs the full
> pthreads library.

Well, actually I tried to run configure --enable-thread-safety on a
MinGW platform and got:
configure: error: pthread.h not found, required for --enable-thread-safetyYou need to run the 'configure' program
first.See the file'INSTALL' for installation instructions.make: *** [all] Error 1
 

Can we not compile --enable-thread-safety without pthreads on Win32?  I
am thinking that is true because we are going to need pthreads for ecpg.

> > 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.
> 
> Currently I have it building using the full pthreads library, with 
> 
> static unsigned long
> pq_threadidcallback(void)
> {
> #ifdef WIN32
>      return (unsigned long) pthread_self().p;
> #else
>      return (unsigned long) pthread_self();
> #endif
> }
> 
> I don't know how badly that might be screwed up though - I simply don't
> know enough about pthreads (or win32 threads for that matter - I only
> really use wxWidgets threads or C# threads).

Seems Mangus gave us the proper Win32 function call and I have changed
pthread_self() on Win32 to return DWORD.

> The ideal way would be to port it to win32 threads of course, but
> there's no way I'll have time to do that at the moment with pgAdmin and
> pgInstaller both needing my attention :-(. Anyone else got some time?
> 
> > Also, there doesn't seem to be a good way for users to know 
> > if libpq or
> > ecpg was compiled to be thread-safe.
> 
> No. Mind you, that ties in nicely with a comment that Magnus made to me
> the other day - we could really use a function to get libpq's version
> number. Something similar (for 8.2 of course) could tell us more about
> it, such as thread safetyness.

True.

> Anyhoo, I can patch ecpglib to use the full pthreads with my hack above
> if people think that is the way to go for the time being.

OK.

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