The thread support has not been tested particularly hard, and depends on SBCL threads which have not themselves been tested particularly hard. Note in particular that the number of worker threads is fixed where it should really be adjusted dynamically to cope with load. If you run into weird threading bugs, (a) I'd like to know about anything you can reproduce, (b) the serve-event support is probbaly more stable.
If you're using threads with SBCL, it gets easier if you're also using sb-aclrepl (require 'sb-aclrepl). If you get a "debugger invoked" message followed by "Thread n suspended", you can use the :focus command to switch that thread to the foreground. When you exit the debugger by selecting any restart, the thread will background before continuing.
CL-USER(16): (araneida::install-handlers) (18770 18769 18768 18767 18766) CL-USER(19): debugger invoked on condition of type UNBOUND-VARIABLE: The variable ARANEIDA::HEADERS is unbound. Thread 18766 suspended CL-USER(19): :fo 18766 Focusing on next thread waiting waiting for the debugger restarts (invokable by number or by possibly-abbreviated name): 0: [DESTROY-THREAD] Destroy this thread (18766) (ARANEIDA::READ-HEADERS #<FILE-STREAM for "descriptor 7" {9D37E91}>)Note that a thread in the debugger will eventually timeout and return to handling requests. The timeout (in seconds) is given by *handler-timeout* and the default value of 60 is probably wrong for just about everything.