 
> Another option would be to create thread local hashtable or other lookup
> structure to which you would register a structure for a particular .c 
> file or group of files.
> 
> You could then define the structures you need locally without 
> affecting other parts of the codebase.
> 
> 
> 
> Myron Scott

A slight variant on this idea would be to mask the variables themselves,
using macrology on a hash keyed on the threadID.

To illustrate:
	MyProc->errType

would, on a threaded system, become something like:
	((PGProc*)ThreadLocalHash(MyProc,GetCurrentThreadID()))->errType

I'm imagining that an approach like this would fit in very nicely with the
existing code. Not the most performance friendly solution however (and I'm
guessing that there might be a place or two where this might be important
:-).

Just a thought,
Claudio

--- 
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/emailpolicy.html

Fri, 26 Sep 2003 15:57:55 +1000
Claudio Natoli <claudio.natoli@memetrics.com>
Re: Threads vs Processes 