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

Re: [HACKERS] Threads vs Processes

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>,<pgsql-hackers(at)postgresql(dot)org>, <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] Threads vs Processes
Date: 2003-09-27 05:20:22
Message-ID: 20030927131911.X15218-100000@houston.familyhealth.com.au (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
> > 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
> from the postmaster.  Bruce has been trying to fix that by having the
> subprocesses somehow reload or re-deduce all those variables; which
> is messy, bug-prone, and probably race-condition-prone too.  In a
> threaded implementation it would maybe be relatively easy to initialize
> a new thread's TLS by copying the postmaster thread's TLS, in which case
> a whole pile of as-yet-unwritten Windows-only code won't be needed.

Kepp in mind though all the cool things that could be done if we had
thread capabilities.  eg. evaluating different subexpressings on
fdifferent cpuis for the one query, etc.

Chris



In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2003-09-27 05:35:24
Subject: Re: 2-phase commit
Previous:From: Christopher Kings-LynneDate: 2003-09-27 05:09:11
Subject: Re: pg_get_triggerdef pretty printing

pgsql-hackers-win32 by date

Next:From: Andrew DunstanDate: 2003-10-03 02:59:59
Subject: lib problems
Previous:From: Dann CorbitDate: 2003-09-26 18:12:06
Subject: Re: [HACKERS] Threads vs Processes

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