[MLton] questions on mlton

[Matthew Fluet]

> When I mentioned a ping/pong benchmark, I meant ping/pong in the CML
> sense, not the networking sense.

IIRC, when I compared the SML/NJ and MLton on the ping-pong benchmark in
the tests/ directory, SML/NJ was doing a little better than MLton in pure
throughput.  MLton's threads are a little more heavy-weight than SML/NJ's
continuations, but it's pretty clear that there is some fat there that
could be trimmed.

> I asked about the details of MLton's threads because it seems easy to
> get this stuff wrong. E.g. deadlocked heavyweight threads (from
> speculative communication) that can't get reclaimed, space leaks (as
> described in "Safe-for-Space threads in Standard ML") or uncaught
> exception funniness.

Indeed.  We've always envisioned building a more user friendly veneer
(like CML) on top of MLton's thread primitives, because they can be
tricky.  In particular, their one-shot nature seems to be a little hard to
grasp the first-time around.

You may be interested in reading through some of the CML related posts on
the MLton mailing list:
  http://mlton.org/pipermail/mlton/2004-May/
In particular, I am not convinced that SML/NJ's implementation is space
effecient, because multi-shot continuations can be held indefinitely on
event queues.  MLton is better off because of the one-shot nature -- when
an event enables a thread, all other copies of the thread waiting in other
event queues get turned into dead threads (of zero size).