[MLton] thread model

[Matthew Fluet]

> > > In the NJ 
> > > implementation of CML this would probably be done by capturing the 
> > > continuation at the scheduling point (the scheduler already uses callcc 
> > > so no extra work here), save it, then to restore the thread to the 
> > > continuation I have saved by placing the saved continuation on the 
> > > scheduling queue inplace of the current continuation for that thread.   
> > > The sceduler takes care of the rest  (ignoring for now  the heap etc).   
> > > With MLton's one shot continuations, is there a  way to emulate this?
> > 
> > Maybe, though you will need to dive deep into the threads implementation.  
> 
> How about just using MLton.Cont?  To "restore" a thread t1 to
> continuation k, simply kill t1 and create a new thread t2 whose sole
> behavior is to throw to k.

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.  If it is the 
user's/thread's discretion to create a restore point, i.e., they 
explicitly call:
  val checkpoint : unit -> Checkpoint.t
and later may call
  vall rollback : Checkpoint.t -> ()
then your approach would work.  (Though it is still tricky to get this 
right in CML.  As John pointed out, killing a thread is tough to get 
right, especially cleaning up all of its incarnations in event queues.)

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.