It looks like I never posted a link to Dan Barlow's 2003 paper, “Adding Native Thread Support to SBCL, Or n Things Every Programmer Should Know About Signal Handling”
From the abstract:
Posted by jjwiseman at February 05, 2005 01:05 PMWe added thread support to the Steel Bank Common Lisp environment on Linux platforms, using the clone() syscall: this presents interesting challenges
- Lisp's introspective abilities and runtime environment requires OS support for things like writing to our own instruction stream, setting breakpoints on ourself, and finding the register contents and faulting address in a SIGSEGV handler. These features are often provided, more seldom tested, and hardly ever documented.
- The primary interface to the Linux kernel is through glibc, and defined in terms of the glibc header files. Accessing this functionality from languages other than C is sometimes harder than it needs to be.
- The de-facto standard for CL multithreaded programming was based on special-purpose Lisp hardware (where, for example, user hooks could be installed directly into the scheduler) and is less suited to today's mainstream computing systems.
Topics include thread-local storage, garbage collection, mmap, breakpoints and ptrace, signal handling, floating point, terminal handling, dynamic linking, and atomic operations. We conclude with a look at some tools (cparse, SWIG, FFIGEN) to help in this area, and some recommendations for kernel and library authors about how they can make life easier for users of non-C languages.
If you found it interesting, you might also want to know that I'm currently in the process of changing SBCL to use pthreads - or at least, I'm adding amd64 support, and using pthreads for it. Whether it's worth backporting this to x86 I haven't yet decided.
Posted by: Daniel Barlow on February 5, 2005 03:23 PM