Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> 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
