When the address-of operator is applied to a thread-local variable, it
is evaluated at run-time and returns the address of the current thread's
instance of that variable. An address so obtained may be used by any
thread. When a thread terminates, any pointers to thread-local variables
in
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
All TLS variables *must* be static (or implicitly static
through extern, i.e. no 'auto' variables)
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
Yes, you are correct.
Tom Lane wrote:
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
Merlin Moncure [EMAIL PROTECTED] 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
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no way for
On Friday 26 September 2003 20:19, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] 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
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no
Bruce Momjian [EMAIL PROTECTED] writes:
One solution is for me to continue with this in the Win32 CVS version
until I have fork/exec() working on Unix, then test on Win32. I think
that could be done in a few weeks, if not less.
Another solution, already mentioned, is to use threads and TLS.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One solution is for me to continue with this in the Win32 CVS version
until I have fork/exec() working on Unix, then test on Win32. I think
that could be done in a few weeks, if not less.
Another solution, already mentioned, is to
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 9:27 AM
To: Bruce Momjian
Cc: Shridhar Daithankar; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Threads vs Processes
Bruce Momjian [EMAIL PROTECTED] writes:
One
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no way for separate-subprocess backends to inherit variable values
Tom Lane writes:
BTW, I've been wondering lately if we'd not be better off to look at
using threading in the Windows port, if it'd help us get around the
fork/exec data transfer problem. I'm not sure that it would,
mind you, but if it would give an answer it might be a lot less painful
than
Claudio Natoli [EMAIL PROTECTED] writes:
FWIW, I've got a threaded version of the WIN32_DEV branch more or less
running (it is a terrible hack job, so NO, no patches... yet :-), as a
proof of concept. Still a work in progress (ok, I've qualified it enough),
but it is showing enough promise to
Claudio Natoli [EMAIL PROTECTED] writes:
FWIW, I've got a threaded version of the WIN32_DEV branch more or less
running (it is a terrible hack job, so NO, no patches... yet :-), as a
proof of concept. Still a work in progress (ok, I've qualified it
enough),
but it is showing enough
Claudio Natoli [EMAIL PROTECTED] writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which variables need to be per-thread
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which variables need
Tom Lane wrote:
Claudio Natoli [EMAIL PROTECTED] writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which
Momjian; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL
for windows)
Claudio Natoli [EMAIL PROTECTED] writes:
FWIW, I've got a threaded version of the WIN32_DEV branch more or less
running (it is a terrible hack job, so
Keith Bottner wrote:
Typically variables that you want to be per-thread are stored in what
Microsoft calls Thread Local Storage (TLS). Variables that you want shared
you can just treat as globals and statics with the appropriate threading
synchronization primitives. With Windows 2000 and later
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 really, really want to avoid doing anything like the above, because it
Both Microsoft and windows compilers support thread local storage. *If*
you guys go with the threading model and *if* it does not introduce any
serious portability issues with gcc (big ifs, and I'm not familiar with
gcc), than IMO TLS is really the way to go. I don't think any
reorganization of
]
[mailto:[EMAIL PROTECTED] On Behalf Of Merlin Moncure
Sent: Thursday, September 25, 2003 2:49 PM
To: Tom Lane
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bruce
Momjian; Shridhar Daithankar; Claudio Natoli
Subject: Re: [HACKERS] Threads vs Processes
Both Microsoft and windows compilers support thread
On Thursday, September 25, 2003, at 10:03 AM, Tom Lane wrote:
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 really,
Merlin Moncure [EMAIL PROTECTED] writes:
All TLS variables *must* be static (or implicitly static
through extern, i.e. no 'auto' variables)
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
and their addresses can not be
assumed
Tom Lane wrote:
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
[...]
Surely the addresses can be assumed constant within a thread. Otherwise
we have a problem here too.
[...]
Taking addresses of TLS variables should be considered
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
Robert wrote:
Hi,
Win32 threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win,
mlw [EMAIL PROTECTED] writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
You are not going to get any buy-in with such ridiculous
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
You are not going to get any
30 matches
Mail list logo
