I was referring to its built-in raw threads including mutexes, condition variables, and what it calls mailboxes (communication channels between threads) as well

I was referring to its built-in raw threads including mutexes, condition variables, and what it calls mailboxes (communication channels between threads) as well as object ports. You can build an Erlang style system easily on top of those (this is Scheme, after all, so you've got macros to help build abstractions, although the system doesn't offer the means to enforce separation (your programs can access symbols that allow to circumvent any separation attempts)), as the Termite project(1) in fact did (also about a decade ago). (1) https://duckduckgo.com/html/?q=gambit+termite https://duckduckgo.com/html/?q=gambit+termite I was mentioning threads since Marc Feeley, its author, was a forerunner in implementing threads on Scheme systems (he authored the threading SRFI (2)). It's a green threading system (support for millions of threads, it doesn't come with support for libev though, so YMMV). (2) http://srfi.schemers.org/srfi-18/ http://srfi.schemers.org/srfi-18/ Thing is, the thread system, like the rest of the system (e.g. he devised an I/O layer that tries to be OS agnostic), tries to come as shiny closed system for the user (with comprehensive user docs), whereas I'd much prefer for the parts to be openly accessible/exchangable. For example I'm often barely using the built-in OS-agnostic I/O layer and instead wrote interfaces to POSIX via the FFI. And I don't use the threading system often. My biggest use case for multi-threading is SMP support which I need to do by running separate Gambit instances (or by way of fork), accessing a common storage layer implemented via POSIX (currently in the works, and I'm writing it in a way that should make it easy for me to move to other Scheme systems). In essence, from my point of view it's a system from academia with a quite explicit attempt to be practical for industrial use but falling short on the latter front pretty much exactly because it tries to do the latter itself.