Re: Win32 Thread safetyness

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 28 August 2005 18:19
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> I poked around this one.  The SSL locking documentation is at:
>
>   http://www.die.net/doc/linux/man/man3/crypto_set_id_callback.3.html
>
> The description isn't clear.  When they talk about locking_function()
> and id_function(void), they are talking about arguments to the SSL
> functions listed above, not actual SSL functions.
>
> 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 unsigned long value, but we have no choice, so we
> have to do it.  (I have added a comment to libpq code mentioning the
> reason for the cast.)  An additional item in the manual is:
>
>     id_function(void) is a function that returns a thread
> ID. It is not
>     needed on Windows nor on platforms where getpid()
> returns a different ID
>     for each thread (most notably Linux).
>
> 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.

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

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.

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.

Regards, Dave.