Steel Bank Common Lisp

Update of /cvsroot/sbcl/sbcl
In directory sc8-pr-cvs1:/tmp/cvs-serv27362

Modified Files:
      Tag: dan_native_threads_branch
	version.lisp-expr TODO.dan 
Log Message:
0.7.9.54.thread.4
	Experimental native threads branch: #-any-expectation-of-utility

	Runtime: changes to SymbolValue and SetSymbolValue signature; 
	these both now take an additional argument for the thread in which
	to look up values.

	All callers of the above functions updated to call with current thread,
	initial thread, or all-threads-in-turn as appropriate

	init_thread now copies tls vector from current thread instead of always
	from the initial thread



Index: version.lisp-expr
===================================================================
RCS file: /cvsroot/sbcl/sbcl/version.lisp-expr,v
retrieving revision 1.662.2.2
retrieving revision 1.662.2.3
diff -u -d -r1.662.2.2 -r1.662.2.3
--- version.lisp-expr	24 Nov 2002 13:21:51 -0000	1.662.2.2
+++ version.lisp-expr	25 Nov 2002 17:58:36 -0000	1.662.2.3
@@ -18,4 +18,4 @@
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
 
-"0.7.9.54.thread.3"
+"0.7.9.54.thread.4"

Index: TODO.dan
===================================================================
RCS file: /cvsroot/sbcl/sbcl/Attic/TODO.dan,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -d -r1.1.2.2 -r1.1.2.3
--- TODO.dan	24 Nov 2002 13:14:15 -0000	1.1.2.2
+++ TODO.dan	25 Nov 2002 17:58:36 -0000	1.1.2.3
@@ -11,25 +11,34 @@
 
 7) some static symbols need attention
 
-    ;; these are per-thread indexes into binding stack, I think
+    ;; these are per-thread indexes into binding stack, so will
+    ;; work if SymbolValue knows how to look up tls values
     *current-catch-block*
     *current-unwind-protect-block*
     *binding-stack-pointer*
 
-    ;; interrupt handling.  these all need attention
+    ;; interrupt handling.  these two are assigned but not bound, and
+    ;; probably should be visible across threads (so are ok)
     *pseudo-atomic-atomic*
     *pseudo-atomic-interrupted*
-    sb!unix::*interrupt-pending*
+
+    ;; do we need separate interrupt contexts per thread?  very
+    ;; probably, yes.  A gets interrupted, B gets interrupted, 
+    ;; A returns from handler before B returns from handler.
+    ;; So, bind this to 0 when each thread starts executing,
+    ;; and all's well
     *free-interrupt-context-index*
-    sb!unix::*interrupts-enabled*
+
+    ;; used for without-interrupts in much the same way as the
+    ;; *pseudo-atomic-...* variables are used for PA.  I think
+    ;; these will be OK if bound to T,0 on thread startup
+    sb!unix::*interrupts-enabled*  
+    sb!unix::*interrupt-pending*
 
     ;; either we have to lock around this, or provide each thread its
     ;; own region
     *allocation-pointer*
 
-8) after doing 7, fix up the things that are expected to happen
-   per-thread (e.g. binding stack scavenging)
-
 9) when creating a new thread, initialise dynamic bindings from
    current thread, not from initial thread
 
@@ -41,3 +50,16 @@
 
 13) fix other runtime stuff that has been temporarily ripped out
  - control stack scrubbing and bounds checking
+
+14) allocation and gc needs fairly serious attention.  There is only
+    one ALLOCATION-POINTER, access to which is not locked other (other
+    than by PA).
+
+15) it would be nice to have a faster way to find the current thread
+    from C than calling getpid().  For x86 we can write a bit of asm
+    to find the thread pointer in dynamic_values_start[1] and have it
+    stored there at thread init.  For other ports something more
+    complicated needs doing, unless we can find a register to use for
+    the tls base that C promises not to overwrite.  
+
+16) interrupt contexts: we need per-thread interrupt context arrays