Michael Sperber [Mr. Preprocessor] writes:
> No. The way Richard has solved this is by allocating a separate VM to
> each real processor. The thread representation basically stays the
> way it is. Saying that Scheme 48 threads "aren't real" is merely a
> confusion of terminology.
Wow, that sounds non-portable. Does he have a paper or doc on all this
new threads stuff, or should I just pour over the code as usual?
> Brian> So then I'm fine with it, as long as I have a way to multiplex N
> Brian> over M threads where N>>M.
> Any application that does this will only become slower because of it.
I'm not sure of the rationale behind this statement. Any application
that tries to use what I call a "thread per client" model ends up
drowning in both application contention issues, or external ones such as
database connections. especially in online transaction processing apps,
you really need to design your concurrency model, deciding how many
resources to dedicate to each type of transaction, how to limit
concurrency in certain places to remove contention etc. just throwing a
1000 threads at the problem only bogs down such systems.