From: Daniel B. <da...@us...> - 2003-02-22 18:19:13
|
Update of /cvsroot/sbcl/sbcl In directory sc8-pr-cvs1:/tmp/cvs-serv30419 Modified Files: Tag: dan_native_threads_2_branch TODO.dan version.lisp-expr Log Message: 0.7.11.10.thread.12 Initial documentation braindump Update TODO list Index: TODO.dan =================================================================== RCS file: /cvsroot/sbcl/sbcl/Attic/TODO.dan,v retrieving revision 1.1.4.2 retrieving revision 1.1.4.3 diff -u -d -r1.1.4.2 -r1.1.4.3 --- TODO.dan 22 Jan 2003 12:49:14 -0000 1.1.4.2 +++ TODO.dan 22 Feb 2003 18:19:08 -0000 1.1.4.3 @@ -1,102 +1,81 @@ -*- Text -*- - * design issues -** What API to export? - -Not interested, really, in supporting the full symbolics stack-groups -crud (whostate, run-reasons, etc). Someone else can slap extra stuff -(thread names, for example) around us. One possible approach is that -taken by corman, where the acl-like MP package keeps a hash table of -thread id -> 'process' - -We're going to use "smallish integer" as thread id from Lisp. For -Linux, because we can, it will be the PID. Note that the tls base -register already points to the current thread, so we have most of the -usually-relevant details at hand already. - ** locking for library functions -Slap this or something like it around each unsafe function. Watch the -code size go boom bigga bigga bing +We've got a *big-compiler-lock* around all use of the compiler and +fasloader (they are mutually recursive in the presence of eval-when +forms) -#+stack-grows-downward-not-upward -(unless (and (sap>= (control-stack-end) (mutex-value *big-library-lock*)) - (sap> (mutex-value *big-library-lock*) (sb-vm::current-fp))) - (get-mutex *big-library-lock* (sb-vm::current-fp))) -,@body -(when (eql (mutex-value *big-library-lock*) (sb-vm::current-fp)) - (free-mutex *big-library-lock*))) - -it would be nice if we could confine this to fewer entry points than -there are functions in SBCL +Other areas that may need serious serialization are +the disassembler +pcl (ha ha ha) +the printer? +the reader? -Debugging: +* seriously broken : affecting correct running -Some threads open a terminal, bind *std{in,out,err}* streams, and start a -listener. That's OK, they'll drop into a break loop if anything goes -wrong in them. Other threads don't. They'll end up writing to the -initial thread's sb!impl::*stderr* instead. +1) allocation locking still not completely done: we're not sure what +happens if two threads simultaneously create a new region, but the +desired effect is "nothing bad" -We could do a handler-bind at thread startup, to make an error handler -that does a pty open, then write to the master and sends sb!impl::*stderr* -(assumed to be connected to emacs or something like it) a specially -formatted message saying "now open /dev/pts/slave because we want to -run a break loop in it". We need to sort out the rather crap pty -handling anyway - master = open("/dev/ptmx", O_RDWR); - grantpt(master); - unlockpt(master); - slave=open(ptsname(fd), O_RDWR); +2) need spinlock implementation in C +2a) lock around all_threads +2b) allocation locking, see (1) +2c) add_thread_to_queue -* seriously broken : affecting correct running +3) setup_i386_stack_scav in purify.c needs doing for multiple threads -10) locking, in general: waiting for locks +4) need some command to switch the foreground process -we would like some mechanism to sleep and be woken on lock contention. -sys_futex will be in 2.6, but is not in 2.4 (though there are patches, -and it may be that the red hat kernel has merged them). In the -meantime, we probably have to fake something with signals and maybe -sigwait(). This means we need to manage our own queues too +i) get spinlock +ii) thread on queue? shuffle it to head, release spinlock +iii) thread not on queue? + release spinlock + Send it SIGTRAP + when it appears on the queue, repeat from step i) +iv) free mutex -We presently do something a bit less sophisticated: just loop calling -sleep(.1) while we wait. Tuning spin retry attempts vs -scheduler-friendly attempts is not possible without knowing the lock -contention. So, we could just pass that decision onto the user. If -2.6 is going to be widely used in the next six months or so, this -could be a win. +5) background/stopped threads need to ignore SIGINT -14) allocation locking still not completely done: we're not sure what -happens if two threads simultaneously create a new region, but the -desired effect is "nothing bad" +6) when a foreground thread exits, we should pick some other thread to +be foreground next. For best results this needs to be done by the +parent thread (the child could have exited in an abrupt fashion) and +entails (free-mutex *session-lock*) - the next in line will pick up. -setup_i386_stack_scav in purify.c needs doing for multiple threads? +What do we do if there are no remaining foreground threads, but there +are background threads? (a) exit, (b) sit here quietly, (c) attempt +to start a foreground thread, (d) background the toplevel as well? +7) make-listener-thread should attempt controlling tty stuff so that ^C +can be delivered to it * broken but uninteresting or cosmetic -2) grow tlv when full +8) grow tlv when full -12) fix ROOM +9) fix ROOM -13) fix other runtime stuff that has been temporarily ripped out +10) reuse ldt slots belonging to dead threads + +11) fix other runtime stuff that has been temporarily ripped out - control stack scrubbing, chiefly +12) look critically at some of the asserts and loses scattered + throughout C and work out a sane error recovery strategy that + doesn't involve dying every time + +13) we're not actually SMP-safe, because we use CMPXCHG without a LOCK + prefix. It would be nice to have some smart way to detect SMP + * code cleanup -23) Some of the static symbols also have static tls offsets and the +14) Some of the static symbols also have static tls offsets and the code that accesses them could be a lot shorter (faster is nice, but avoiding allocating a register is even nicer) if these were known at host-1 compile time -15) we'd like a faster way to find the current thread from C than - calling getpid(). For x86, for now, we can write a bit of asm to - dereference %gs:(offsetof self), 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. - -22) allocate-on-same-page stuff in gc_find_freeish_pages needs +15) allocate-on-same-page stuff in gc_find_freeish_pages needs re-enabling to avoid massive heap fragmentation - Index: version.lisp-expr =================================================================== RCS file: /cvsroot/sbcl/sbcl/version.lisp-expr,v retrieving revision 1.724.2.10 retrieving revision 1.724.2.11 diff -u -d -r1.724.2.10 -r1.724.2.11 --- version.lisp-expr 22 Feb 2003 02:39:37 -0000 1.724.2.10 +++ version.lisp-expr 22 Feb 2003 18:19:08 -0000 1.724.2.11 @@ -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.11.10.thread.10" +"0.7.11.10.thread.12" |