Shridhar Daithankar <[EMAIL PROTECTED]> writes:
One thing that can be done is to arrange all globals/statics in a structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I know.
I have following half baked solution. Obviously it won't be as good and automatic as __declspec(thread). But still... Just for starters
1. Put all static/global variables in .h file. No more in .c files
2. Encapsulate them in a #define.
3. Create a new header files which includes lot of macro invocations. That way we expand a macro definition, the structure definition changes on recompile.
Like in a.h
a.h
---
#define module1 int a;\
int b;
---b.h
---
typedef struct
{
module1
module2
} globalDataStructure---
Whoever includes a.h earlier, needs to include b.h now. That way things will flow smoothly. This could be optional but I would rather not include a.h anymore as a good practice.
4. Add a macro definition for initialization function. The global initialization function will again invoke macro implementations which are free to redirect it to any function of choice.
That way we can maintain variables in modules that they are but still put them in a single compile unit when they get compiled. Only one file b.h, need to be maintained for addition of new files. The variables would be taken care of in the respective modules. ( This could nicely be done in C++ using classes but thats a
altogether different subject.)
The changes to actual C code obviously need to follow.
I agree that's messy and non transparent. but it still retains distributed nature of variable declarations and maintenance thereof..
But I feel we are missing the point. Last time threads for unix builds were discussed, one of the good suggestion was to use them to distribute load across CPU's rather than using thread per connection. Personally I don't think postgresql is missing lot of performance by using process/connection rather than thread/connection(Except for slowaris and windows perhaps).
Even on windows, the time taken for a new connection is unlikely to be an issue, I feel.
We really don't need threads to replace existing functionality. That would be dog work.
If we are writing new functionality, we can do it clean and portable way rather than fiddling with existing code. Changing working code is always a messy business irrespective of technicalities involved. As a support engineer, I can attest that.
Shridhar
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
