Many Lisps (and Common Lisp) had 'green threads' decades ago. Green threads are not preemptively scheduled by the OS/hardware. Multi-Processor Lisps were new an

Many Lisps (and Common Lisp) had 'green threads' decades ago. Green threads are not preemptively scheduled by the OS/hardware. Multi-Processor Lisps were new and very rare (like the Lisp&Scheme for BBN Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly or the Lisp for massive parallel Connection Machine). So the green threads then were mostly on a single core. Many Common Lisps moved to native threads in the last two decades because that provided preemptively scheduled threads on multi-core machines. Early examples were Corman Lisp (on Windows) and Scieneer CL (a commercial fork of CMUCL). Native threads have also advantages when interfacing to the OS. Implementations like SBCL, LispWorks, Allegro CL and others provide native threads and support multi-core machines. In the LispWorks development environment I use, every IDE tool runs in its own thread on a multicore CPU. The big problem most implementations face is getting a parallel and/or concurrent garbage collector. For the JVM such things exist in various forms. Allegro CL has something like a parallel GC. I would maybe use something like lparallel. https://lparallel.org/overview/ https://lparallel.org/overview/ Other libs are listed here: https://cliki.net/concurrency https://cliki.net/concurrency