Skip site navigation (1) Skip section navigation (2)

Re: Win32 Thread safetyness

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Win32 Thread safetyness
Date: 2005-08-28 18:17:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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:

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?



pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-08-28 18:53:50
Subject: Re: Win32 Thread safetyness
Previous:From: Tom LaneDate: 2005-08-28 18:04:43
Subject: Re: Segfault Exiting psql

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group