Both Microsoft and windows compilers support thread local storage. *If*
you guys go with the threading model and *if* it does not introduce any
serious portability issues with gcc (big ifs, and I'm not familiar with
gcc), than IMO TLS is really the way to go. I don't think any
reorganization of postgres's static variables is necessary. TLS is
implemented in the win32 API, not the C Libs, so by giving up the syntax
sugar you can make direct calls and keep compiler independence in win32.
Microsoft syntax is __desclspec(thread) and Borland syntax is simply
__thread. All TLS variables *must* be static (or implicitly static
through extern, i.e. no 'auto' variables) and their addresses can not be
assumed to be constant.
Taking addresses of TLS variables should be considered illegal, as well
as pointers to TLS variables. Another gotcha is that DLLs that have
__thread variables will GPF if loaded with LoadLibrary (they should be
static linked). Of course, pg does not use dlls, but it's worth noting.
Merlin
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
