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-safety
You 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073