[MLton] questions on mlton

[Heath Putnam]

It looks like I've got to upgrade from OpenBSD 3.4 in order to run the
new MLton. OpenBSD 3.4 has a slightly different signal API (looks like
NetBSD) than what MLton uses. I get errors in gc.c.

It might be nice to put something in the wiki that says what versions
MLton has been tested with.

After I get things working and do some experiments I'm sure I'll have
more questions.

Heath



Matthew Fluet <fluet@cs.cornell.edu> writes:

> > 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).