SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

Documentation

• See first the the SBCL Users manual.

• Daniel Barlow also presented a paper on the subject, at the UKUUG Summer 2003 Linux Developers' Conference.

• Older implementation notes can be found at http://ww.telent.net/diary/2002/11/#28.43357 and http://ww.telent.net/diary/2003/1/#17.8242. There is probably other thread-related stuff in that diary as well: please feel free to add links if you find them

During GC, each thread other than the one GCing is signalled with SIG_STOP_FOR_GC, which is a spare posix realtime signal. When it's safe for the thread to process the signal (i.e. it's not in pseudo-atomic) it goes to sleep by blocking all signals and calling sigwaitinfo(). This is to ensure that any signals from the outside world (e.g. SIGIO from streams, SIGALRM from timers) are blocked until it resumes. When GC is finished, the GCing thread sends a second SIG_STOP_FOR_GC.

Current TODO list

* Actual bugs

3) setup_i386_stack_scav in purify.c needs doing for multiple threads

58) thread hooks for TRACE would make it usable for debugging (some number of) locking problems

66) profiling is currently racy. details? I can't remember

* broken but uninteresting or cosmetic

8) grow tlv when full

9) make ROOM display stacks from other threads as well as the current one

* for future consideration

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

64) Take advantage of new NPTL feature: use set_thread_area with TLS_FLAG_ENTRY2 (the "Wine" segment) to get GDT slot which the kernel switches per-thread instead of using the lDT (which is limited to 8192 threads). Not that, I concede, we're probably ready for 8000 threads anyway, but it'd be nice.

65) Reuse the stack areas of dead threads, to make repeated thread creation much faster. Needs some thought (and ideally, some benchmarking) to decide how long to keep the memory allocated after death.

66) Porting to other platforms. This is mostly about Removing futexes and porting GENCGC.

Page in this topic: MP  

Also linked from: Cyrus Harmon   GENCGC   index   Removing futexes   Threading-ppc  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively