[MLton] thread model

[Matthew Fluet]

> > But there is no way to reify a MLton.Thread.t to a MLton.Cont.t.
> > 
> > I really depends on what kind of API Luke wants to provide.  
> 
> Makes sense.
> 
> > If it is the scheduler's discretion to create the restore point, then all
> > it has in hand is a (suspended) MLton.Thread.t (and sometimes just a
> > MLton.Thread.Runnable.t), then you need something else.
> 
> A suspended thread might be OK, since one could do some trickery with
> prepend to throw to it and do the callcc.  But a Runnable.t defintely
> requires runtime support.  So I see your point.  Thread.copy seems
> like a sensible operation to have anyway.

Luke, you may be interested in reading the following message/thread:
   http://mlton.org/pipermail/mlton/2001-December/021114.html
which explains how we intend the primitive thread operations to be used.