If Scheme is so good why MIT drops it?

[Carl Banks]

On Jul 22, 5:27 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Carl Banks <pavlovevide... at gmail.com> writes:
> > I don't think your fantasy async-only all-green-thread langauge
> > implementation is possible anyway.
>
> Erlang and GHC both work like that, quite successfully:
>
>  http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&l...

I am not suggesting that you can't do a lot of things with async I/O.
But can you do *everything* that native threads can do?  I don't think
so.

So when you asked:

"Why is that [native threading] such an advantage?  Green threads work
fine if you just
organize the i/o system to never block."

Well, the answer is they don't always work fine.  Just organizing the
I/O system never to block won't cut it, since things other than I/O
block.  For green threads to work fine all the time you have to be
able organize your entire system never to block, and I don't think
it's possible on the common OSes in use today.  Until that happens,
there will always be advantages to being able to use native threads on
a single core.


> > How would you wait on a pipe in one thread, a socket in another, a
> > semaphore in a third?  
>
> You can select on pipes and sockets, I think.  Not sure about
> semaphores.  

So you made a claim that "green threads work fine", and rhetorically
suggested that native threads had no advantages, yet you're not even
100% sure you can select on both pipes and sockets (both common forms
of I/O), let alone semaphores?

[You can select on sockets and pipes in Unix, not in Windows, although
on Windows I think there are other ways to do it besides the select
call.]


> > (Are there any popular OSes that offer a unified polling interface to
> > all possible synchronizations?)  And what do you do about drivers or
> > libraries that make underlying blocking calls?  What if you have a
> > busy calculation going on in the background?
>
> 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?

> 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.  Well that happens at the OS-level too but the OS can respond
to interrupts and task switch between timer ticks at finer intervals.
Back in my DOS days I wrote user programs that responded to I/O
interrupts, but it doesn't seem to be common practice in modern OSes
to easily allow this.


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.


Carl Banks