Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Threads vs Processes

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [HACKERS] Threads vs Processes
Date: 2003-09-26 12:34:11
Message-ID: 3F743243.5060900@persistent.co.in (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
Tom Lane wrote:

> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Lamar OwenDate: 2003-09-26 13:22:26
Subject: Re: [ADMIN] postgres 6.2 vacuum
Previous:From: Merlin MoncureDate: 2003-09-26 12:11:44
Subject: Re: [HACKERS] Threads vs Processes

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2003-09-26 14:43:22
Subject: Re: [HACKERS] Threads vs Processes
Previous:From: Merlin MoncureDate: 2003-09-26 12:11:44
Subject: Re: [HACKERS] Threads vs Processes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group