Thread: Threads vs Processes (was: NuSphere and PostgreSQL for windows)
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 > solving the data transfer problem directly. Some coincidence. Was just about to post a message to the hackers-win32 list, asking if anyone was considering using threads for the Windows port, and why/if sub-processes were the preferred option (from the TODO items on http://momjian.postgresql.org/main/writings/pgsql/win32.html mention CreateProcess). Having looked at the code for the first time over the past day and a half, I'm quite sure that using threads is the easier option (and, generally, replacing fork/exec with winthreads is easier than using CreateProcess). 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 convince me that threading is the way to go for the Win32 port. Anyone else experienced with the code base care to weigh in on this? Cheers, 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
Claudio Natoli <claudio.natoli@memetrics.com> 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 convince me that threading is the way to
> go for the Win32 port.
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
regards, tom lane
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 you have up to 1088
TLS locations that you can use, of course these can be pointers to memory
which can store whatever you want.
Keith
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Thursday, September 25, 2003 9:17 AM
To: Claudio Natoli
Cc: Robert Treat; Bruce Momjian; pgsql-hackers@postgresql.org;
pgsql-hackers-win32@postgresql.org
Subject: Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL
for windows)
Claudio Natoli <claudio.natoli@memetrics.com> 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 convince me that
> threading is the way to go for the Win32 port.
How are you dealing with the issue of wanting some static variables to be
per-thread and others not?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
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 you have up to 1088 > TLS locations that you can use, of course these can be pointers to memory > which can store whatever you want. Goes GCC on Windows support TLS, or only Microsoft compilers? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I do not know for sure to what extent GCC supports TLS on Windows. There are compiler extensions that can be used under Windows, like __declspec(thread) which automagically handles the declaration and initialization of the TLS variable rather than dynamically calling the TlsAlloc, TlsFree, TlsSetValue, and TlsGetValue. I also believe they have extensions in the compiler that recognize that you are using TLS (when using __declspec) and therefore allow you to access them without having to use the TlsSetValue and TlsGetValue. Sorry I don't about GCC, but I hope this additional information helps. Keith -----Original Message----- From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] Sent: Thursday, September 25, 2003 11:57 AM To: Keith Bottner Cc: 'Tom Lane'; 'Claudio Natoli'; 'Robert Treat'; pgsql-hackers@postgresql.org; pgsql-hackers-win32@postgresql.org Subject: Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for windows) 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 you > have up to 1088 TLS locations that you can use, of course these can be > pointers to memory which can store whatever you want. Goes GCC on Windows support TLS, or only Microsoft compilers? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073