users are, apparently, beginning to take notice of changes pushed to
master earlier this month, and I would like to say a few words on the
current state of things, if only to manage expectations...
Two years ago Dmitry Kalyanov wrote:
Quoting Kalyanov Dmitry (kalyanov.dmitry@...):
> I'd like to announce my work on addition of threads to Windows port of SBCL.
> The code is available at http://github.com/dmitryvk/sbcl-win32-threads in
> 'tib-3' branch. Binary installer is available at
> It's still alpha-quality and performance may suffer (due to inefficient GC
> safepoint implementation). I'd be glad for review or bug reports.
And rather belatedly, some support for sb-thread has arrived on master.
I'd like to emphasize the following:
1. Many thanks to Dmitry and Anton for their work, and sorry it took
us so long! Windows had not been a priority for SBCL for quite
some time, but the message to users now must be that things are
changing; we're taking Windows improvements rather seriously,
and after all, we "are taking patches" again.
2. Yet I still recommend that users deploy Windows applications based
on Anton's current branch; it includes many improvements not yet on
master. In particular, AMD64 users have no other option anyway,
but many other features and bugfixes also still remain to be merged.
3. However, it would be helpful if users could occasionally test
official SBCL builds to see if "upstream" SBCL already meets their
needs, and possibly report bugs that have crept in during the
What has been merged is thread support as such, based on Dmitry's work,
but brought forward to Anton's original stop-the-world safepoint
protocol changes (from roughly a year ago, i.e. still lacking some
important fixes dating back to late 2011), and with just sufficient
support for I/O interruptibility to get SLIME going.
All other features and bug fixes will arrive in the next few releases
(if everything goes as planned), step by step.
For those interested in low-level details: Safepoints (the
SIG_STOP_FOR_GC replacement), thruptions (SIGPIPE replacement), and
wtimers (SIGALRM) are also available for Linux and Solaris on x86 and
amd64, but are a completely optional, experimental feature on those.
For these platforms, bug reports (including easily reproducible test
cases :-)) would be very helpful.
Thanks in advance for testing, and let's please keep the celebrations of
the merge rather low-key until it's actually done. :-)