If Scheme is so good why MIT drops it?

[Paul Rubin]

Carl Banks <pavlovevidence at gmail.com> writes:
> > I don't think the concept of "drivers" applies to user-mode programs.
> > For FFI calls you would use an OS thread.
> That's contrary to the hypothesis, isn't it?

Yeah, it would have been better to say, green threads are ok for most
typical forms of i/o concurrency, but OS threads are still necessary
for some things.  An FFI call in particular isn't exactly under the
control of your language's runtime system; it has to be treated
more like an external program.

OS thread switching is much more expensive than green thread
switching, so it's still preferable to use green threads when
possible.

> > The language runtime switches between busy computation threads on
> > a timer tick.
> This would seem to result in a tradeoff between performance and low-
> latency. 

GHC appears to use a 100 hz timer, which I'd expect to be fast enough
for interactive applications while still not causing too much cpu
load.  I don't know if it has a way to assign priorities to
microthreads (e.g. if you have one running your program's GUI) though.

I don't think either Python or GHC can implement hard-real-time
latency because they both use stop-the-world garbage collection.
E.g. in Python, releasing the last reference to a large list or dict
can take a long time.

> And Paul, if I'm being a little hard on you here, it's not that I'm
> taking issue with your own claim so much as with your dismissal of
> mine.

Well, the issue was why Python uses native threads pervasively.  As
far as I can tell, it's just an implementation artifact that has no
really compelling justification.