Lee Kindness wrote: > From: "Bruce Momjian" <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
