Re: [HACKERS] Threads vs Processes

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-hackers-win32(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: [HACKERS] Threads vs Processes
Date: 2003-09-26 15:50:47
Message-ID: 3F746057.4090108@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

Tom Lane wrote:

>"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>Surely the addresses can be assumed constant within a thread.
>>>Otherwise we have a problem here too.
>>>
>>>
>
>
>
>>Quoting from the MSDN:
>>The address of a thread local object is not considered constant, and any
>>expression involving such an address is not considered a constant
>>expression.
>>
>>
>
>Ah. That's probably reasonable. Still a bit of a PITA for us, as there
>are various places that do give a static variable an initializer
>pointing to another static. But that could be worked around I think.
>I thought you were saying that the compiler would forbid taking a TLS
>variable's address even at runtime.
>
>

Tom,

you wrote you wouldn't like the idea of a struct representing the now
global variables for a thread, because this would mean that every module
would need to access it, and any change of a module-local variable would
affect the complete backend.

This could be worked around:
If that global struct is just a list of pointers to memory blocks, each
block representing the opaque local data of a module, this can be
avoided. This could be duplicated easily for thread creation, if zwo
ints representing mem block size and size to copy for each block is
included. Additional pointers for creation and cleanup functions could
help for more special initializations.

This would make the thing independent of fancy compiler features and
platforms.

Regards,
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2003-09-26 16:00:59 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 15:30:59 Re: invalid tid errors in latest 7.3.4 stable.

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Bruce Momjian 2003-09-26 16:15:16 Re: [HACKERS] Threads vs Processes
Previous Message Merlin Moncure 2003-09-26 15:43:27 Re: [HACKERS] Threads vs Processes