Cc: address@hidden, address@hidden, address@hidden
From: Daniel Colascione <address@hidden>
Date: Tue, 1 Nov 2016 09:45:41 -0700
Name one system we support that both _has_ threads and that doesn't have
a thread-safe system malloc. If we're using our own malloc and _that_
isn't thread-safe, that doesn't count. I insist that on modern systems,
the malloc and free that come with libc are thread safe.
You can insist all you like, it won't change my mind: thread-safety in
malloc is only now becoming widespread and reliable enough, and older
systems where there are various bugs in that regard are still with us
in significant numbers. Just google the keywords, and you will see
the bug reports and their dates.
Allocation of lisp objects is different. _That_ isn't thread safe
right now. The easiest way to address this problem is a GIL.
GIL hurts performance so much that I'd question any GIL-based design
that attempts to support off-loading CPU-intensive tasks to worker
threads.
On what basis do you make this claim? As someone mentioned previously,
that Python paper isn't really relevant, as we're not doing CPU
preemption.
I think we've lost context: this thread is not about the concurrency
branch, where only one thread runs at a time, for which that Python
paper is irrelevant. This thread (or at least what I wrote above) is
about the proposal to have more than one thread that performs
CPU-intensive tasks, so that the main thread could go about its
business. For that, you will definitely want CPU preemption, because
those tasks don't have to run Lisp.