> > 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
> -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 Momj
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 menti
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
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 the
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
express
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
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 separate-sub
"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 a
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
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 cor
> "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
> 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.
>
>
>
> Myr
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 il
"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
> a
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, re
]
[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
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 p
helps.
Keith
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 11:57 AM
To: Keith Bottner
Cc: 'Tom Lane'; 'Claudio Natoli'; 'Robert Treat';
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Thre
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
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 la
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
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 varia
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
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
> 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
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 prom
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
t
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
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 ridicu
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,
31 matches
Mail list logo
