"It sounds hard to believe using a single core is a problem of mzScheme."
(Psst, if you say "mzScheme," I feel the need to remind you that Arc works on the latest versions of Racket, which have long since dropped the name "mzscheme".)
Generally, threads are for concurrency, not necessarily parallelism. They're a workaround for an imperative, sequence-of-side-effects model of computation, which would otherwise force us to choose which subcomputation should come first. In Racket, this kind of workaround is their only purpose.
Racket has two features for parallelism, and they're called "futures" and "places":
I'm finding out about these for the first time, but I'll summarize anyway.
Futures are a lot like threads, but they're specifically for speculative parallelism. They're allowed to break some invariants that threads would have preserved, and (as per the nature of speculative parallelism) some of their computations may be thrown away.
Places use shared-nothing concurrency with message passing, and each place runs in parallel.
So although news.arc does spawn a thread to handle every server request, it would probably need to use Racket's futures to take advantage of multi-core systems--and even then, I'm guessing it would need some fine-tuning to avoid wasting resources. If it used Racket's places, that could make its resource usage easier to reason about (but not necessarily better!), but it would require even more substantial refactoring.
