Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 6b3c8e3

Browse files
committed
Add
1 parent ab2c905 commit 6b3c8e3

File tree

1 file changed

+53
-0
lines changed

1 file changed

+53
-0
lines changed

doc/TODO.detail/thread

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -277,3 +277,56 @@ mkscott@sacadia.com
277277

278278

279279

280+
From bright@fw.wintelcom.net Tue Jan 2 03:02:28 2001
281+
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
282+
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA16169
283+
for <pgman@candle.pha.pa.us>; Tue, 2 Jan 2001 03:02:27 -0500 (EST)
284+
Received: (from bright@localhost)
285+
by fw.wintelcom.net (8.10.0/8.10.0) id f0282Vm10623;
286+
Tue, 2 Jan 2001 00:02:31 -0800 (PST)
287+
Date: Tue, 2 Jan 2001 00:02:31 -0800
288+
From: Alfred Perlstein <bright@wintelcom.net>
289+
To: Bruce Momjian <pgman@candle.pha.pa.us>
290+
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
291+
Subject: Re: [HACKERS] Assuming that TAS() will succeed the first time is verboten
292+
Message-ID: <20010102000230.C19572@fw.wintelcom.net>
293+
References: <9850.978067943@sss.pgh.pa.us> <200101020759.CAA15836@candle.pha.pa.us>
294+
Mime-Version: 1.0
295+
Content-Type: text/plain; charset=us-ascii
296+
Content-Disposition: inline
297+
User-Agent: Mutt/1.2.5i
298+
In-Reply-To: <200101020759.CAA15836@candle.pha.pa.us>; from pgman@candle.pha.pa.us on Tue, Jan 02, 2001 at 02:59:20AM -0500
299+
Status: OR
300+
301+
* Bruce Momjian <pgman@candle.pha.pa.us> [010101 23:59] wrote:
302+
> > Alfred Perlstein <bright@wintelcom.net> writes:
303+
> > > One trick that may help is calling sched_yield(2) on a lock miss,
304+
> > > it's a POSIX call and quite new so you'd need a 'configure' test
305+
> > > for it.
306+
> >
307+
> > The author of the current s_lock code seems to have thought that
308+
> > select() with a zero delay would do the equivalent of sched_yield().
309+
> > I'm not sure if that's true on very many kernels, if indeed any...
310+
> >
311+
> > I doubt we could buy much by depending on sched_yield(); if you want
312+
> > to assume POSIX facilities, ISTM you might as well go for user-space
313+
> > semaphores and forget the whole TAS mechanism.
314+
>
315+
>
316+
> Another issue is that sched_yield brings in the pthreads library/hooks
317+
> on some OS's, which we certainly want to avoid.
318+
319+
I know it's a major undertaking, but since the work is sort of done,
320+
have you guys considered the port to solaris threads and seeing about
321+
making a pthreads port of that?
322+
323+
I know it would probably get you considerable gains under Windows
324+
at the expense of dropping some really really legacy system.
325+
326+
Or you could do what apache (is rumored) does and have it do either
327+
threads or processes or both...
328+
329+
--
330+
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
331+
"I have the heart of a child; I keep it in a jar on my desk."
332+

0 commit comments

Comments
 (0)