Apparently, I still haven't nailed down the thread suspension for SBCL.
Some newly discovered problems are related to calling a Lisp code from the C function funcall.
The thread state was changing incorrectly: thread enters Lisp code which means that the gc_flag should be unset, but it is not the case.
And then the garbage collector skips such a thread and keeps on collecting the garbage while the mutator thread is doing its own business.
Obviously, this causes memory corruption.
Also, the thread state is messed up during stack unwinding.
It looks like that gc_safe should be moved out of the thread struct and made into a proper symbol.
This should ensure correct tracking of thread state during stack unwinding and other thread state changes as the Lisp runtime maintains the dynamic bindings stack.
I've also tackled sockets under Windows. And they are very weird. E.g., one can not simply write, read and poll the socket from different threads. If the read or poll operation has started earlier than a socket write then the write will just block until the read completes. This causes SLIME to not work in multithreaded mode since it uses different threads for writing to and reading from a socket. And I really don't want to go the async IO path.