From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> Lee Kindness wrote:
> > I still think it's worthwhile investigating the use of GCC's __thread
> > storage class specifier to remove the use of pthread_*specific in this
> > case. This would also be a help to the WIN32 port since this specifier
> > maps well to similar constructs in Microsoft's and Borland's compilers
> > (see "thread" item in the TODO at developer.postgresql.org).
> I would like to avoid compiler-specific thread stuff unless tests can
> show a performance benefit.
I think concerns re performance are largely moot - with the thread specific
data performance is much the same as without. However native compiler
support for thread specific data is much more straightforward and
understandable - you simply end up with a variable that can be used like any
other except there is a copy of it for each thread.
To make ECPG thread-safe for WIN32 an additional set of thread calls will
need to be added, and/or similar features to GCC's __thread storage
specifier. If we end up adding these for WIN32 then it may as well be done
for GCC too. I probably will experiment with it a bit (and get some real
performance figure, rather than my hunch!)...
Perhaps a cleaner way is to use an existing thread package with encompasses
the various platform APIs - i.e. APR or ACE, or... But that's a big
discussion, and not one I'm keen to get into at the moment. A more
appropriate time is perhaps once the WIN32 port is completed? It would also
be straightforward to encompass this in an PostgreSQL specific API to wrap
around the various calls we use and, if available, make these no-ops when a
suitable storage class is supplied by the compiler? I'd be happy to write
this API if others saw it as a way forward.
Perhaps someone would like to fwd this on to the hackers-win32 list (I'm not
subscribed) to see what their view is on thread safety in the client
libraries? And what approach they're planning?
L.