Re: call/cc

[Tony Kimball <address@hidden>]

Quoth S. Alexander Jacobson on Tuesday, 11 December:
: Ok, but multithreaded servers are relatively easy to understand.
: Passing contuations around seems harder.  (I've done the former but not
: the later).

Quite the contrary, I think.  Of course most of my professional work
has involved multithreaded servers, and my notions of call/cc-based
server architecture are largely speculative, but the introduction of
threads is bad encapsulation for one thing (sharing the whole memory
space instead of just a region, as in a process/mmap model), and an
inevitable performance problem, for another.

: Why not leave the non-contination code alone instead modify server's OS
: threads to be non-premptive*?  Or allow the language/runtime to specify
: a threading model?  The original unix Java implementations used a
: non-preemptive threading implementation.  If any of that code is still
: around, then it wouldn't be that hard to give users a choice.

Non-premptive threading is either explictly scheduling or implicitly
scheduling.  In the explicitly scheduling case, you've got all the
code impact of a call/cc-based design, with none of the advantages.
In the implicitly scheduling case, you've got a severe performance
problem, in the form of an essentially uncontrollable latency -- no
approach to even soft real-time guarantees is possible, a priori.