email@example.com (Michael Sperber [Mr. Preprocessor])
> >>>>> "Perry" == Perry E Metzger <firstname.lastname@example.org> writes:
> Perry> The research that's been done over the years (I'll provide a
> Perry> bibliography if you want) tends to indicate that thread expense is an
> Perry> operating system issue far more than a language issue.
> Perry, the disagreement we're having is because you have
> misconceptions about the thread system in scsh. Most importantly,
> threads expense is not an OS expense at all in scsh---the thread
> system is userland.
I'm aware of that. However, that's not (ultimately) the point.
> Moreover, the thread systems you're citing (I believe I've read most
> of the work you're referring to) are based on language implementation
> paradigms different from that of scsh---specifically, regarding the
> representation of continuations. This means the costs (space and
> time) associated with threads in scsh are typically an order of
> magnitude less than with the thread systems you're citing.
Thread creation/dispatch would have to be about identical to the costs
of procedure calls to get to the point where they were as cheap as an
event dispatch, and even with the best representations of
continuations for scheme I've read about in the literature don't seem
to permit that, especially if your implementation is compiling to
native code (and thus most procedures are damn cheap).
However, we're going to have to agree to disagree on this. I suspect
you're not going to convince me without showing me something that
scsh's non-native compilation won't make possible (that is, a server
actually managing ten thousand or more clients simultaneously), and it
is quite obvious that I'm not going to convince you, either...