After the beginning of July, SBCL got a thread implementation overhaul, courtesy of Dan Barlow and Gábor Melis. Here's what Gábor wrote about the first round of updates:
The x86 part of Dan's pthread branch is merged with a few fixes.
What do pthreads bring:
- + errno is no longer shared
- + interrupt-thread pinning problem gone
- - signal handling semantics change
- fixed recursive get on session-lock that happened when a gc interrupting get-foreground reaped a thread
- fixed sigint handling: removed broken (by pthread signal handling semantics) sigint enable/disable machinery in favor of sigint-%break looking up the foreground thread and interrupting it, which is itself racy :-(.
- numerous fixes for interrupt-thread
- removed suspend-thread, resume-thread
- destroy-thread is now equivalent to terminate-thread. Maybe a pthread_cancel based implementation is possible.
In the second round of updates, he explained how the user interface looks (emphasis mine):
Executive summary* sb-thread:*current-thread* #<SB-THREAD:THREAD 0 "initial thread"> * (sb-thread:make-thread (lambda ()) :name "good thread") #<SB-THREAD:THREAD 1 "good thread"> * (sb-thread:thread-alive-p *) NIL
The public interface changes
- proper thread objects instead of thread ids
- (MAKE-THREAD FN &KEY NAME) => THREAD
(THREAD-ID THREAD) => INTEGER is different from pid and pthread_t, the initial thread has an id of 0, then next thread has an id of 1, ...[This was removed -xach]
- (THREAD-NAME THREAD): threads have names (useful for debugging, logging)
- (THREAD-ALIVE-P THREAD)
- *CURRENT-THREAD* special is bound in each thread
- (LIST-ALL-THREADS) returns a list of all active threads
(FIND-THREAD THREAD-ID) => THREAD or NIL[ditto -xach]
This work has resulted in some turmoil while things settle and adjust to the changes, but in the long run SBCL's thread implementation should become more portable, more reliable, and easier to use.
- The SBCL Manual section on threads
- Franz's new multiprocess and OS thread model; thread objects are full CLOS instances, and the thread object class may be subclassed
- LispWorks multiprocessing
- Dan Barlow: Native thread support for Steel Bank Common Lisp
- Dan Barlow: Linux kernel vs POSIX API for threads