Add

diff --git a/doc/TODO.detail/thread b/doc/TODO.detail/thread
index 1be245287f9a0a28e865a3e8b344c191b5a18847..555f13a942b42ceab4bb3d2d4156c145bf6b4fc1 100644 (file)
--- a/doc/TODO.detail/thread
+++ b/doc/TODO.detail/thread
@@ -277,3 +277,56 @@ [email protected]
 
 
 
+From [email protected] Tue Jan  2 03:02:28 2001
+Received: from fw.wintelcom.net ([email protected] [209.1.153.20])
+   by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA16169
+   for ; Tue, 2 Jan 2001 03:02:27 -0500 (EST)
+Received: (from bright@localhost)
+   by fw.wintelcom.net (8.10.0/8.10.0) id f0282Vm10623;
+   Tue, 2 Jan 2001 00:02:31 -0800 (PST)
+Date: Tue, 2 Jan 2001 00:02:31 -0800
+From: Alfred Perlstein 
+To: Bruce Momjian 
+Cc: Tom Lane , [email protected]
+Subject: Re: [HACKERS] Assuming that TAS() will succeed the first time is verboten
+Message-ID: <[email protected]>
+References: <[email protected]> <[email protected]>
+Mime-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+User-Agent: Mutt/1.2.5i
+In-Reply-To: <[email protected]>; from [email protected] on Tue, Jan 02, 2001 at 02:59:20AM -0500
+Status: OR
+
+* Bruce Momjian  [010101 23:59] wrote:
+> > Alfred Perlstein  writes:
+> > > One trick that may help is calling sched_yield(2) on a lock miss,
+> > > it's a POSIX call and quite new so you'd need a 'configure' test
+> > > for it.
+> > 
+> > The author of the current s_lock code seems to have thought that
+> > select() with a zero delay would do the equivalent of sched_yield().
+> > I'm not sure if that's true on very many kernels, if indeed any...
+> > 
+> > I doubt we could buy much by depending on sched_yield(); if you want
+> > to assume POSIX facilities, ISTM you might as well go for user-space
+> > semaphores and forget the whole TAS mechanism.
+> 
+> 
+> Another issue is that sched_yield brings in the pthreads library/hooks
+> on some OS's, which we certainly want to avoid.
+
+I know it's a major undertaking, but since the work is sort of done,
+have you guys considered the port to solaris threads and seeing about
+making a pthreads port of that?
+
+I know it would probably get you considerable gains under Windows
+at the expense of dropping some really really legacy system.
+
+Or you could do what apache (is rumored) does and have it do either
+threads or processes or both...
+
+-- 
+-Alfred Perlstein - [[email protected]|[email protected]]
+"I have the heart of a child; I keep it in a jar on my desk."
+