Lee Kindness wrote:
> 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?
I guess my point was that if there isn't a big performance win, why do
compiler specific and POSIX standard both in the same code. The
compiler-specific might be clearer, but if we have to support non-gcc
too, which we do, adding a cleaner solution to one that is already
standard actually makes it look worse.
I don't think MinGW support thread-specific right now (no TLS support),
so we will need native Win32 in there anyway. Adding a third seems like
more confusion.
-- 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