Daniel Barlow - metacircles

n things every programmer should know about signal handling

Paper (DVI) and Paper (PDF) and Paper (TeX) and Slides (LISP) and Notes on slides display software.

Threads (lightweight processes sharing a comon address space) are now a near-standard technique used in many large applications, and supported - in varying ways and to different extents - in many languages and most operating systems. We 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 intalled directly into the scheduler) and is less suited to today's mainstream computing systems.

The talk is low-level and quite technical in nature, so should be interesting to systems/kernel programmers as well as high-level language fans. 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.