[MLton] thread model

[Matthew Fluet]

> I would like to be able to at a particular scheduling point capture a 
> threads continuation.  Then after further exectution of that thread, if 
> I deem necessary, "roll back" to the captured continuation.  

You will of course be unable to "roll back" any imperative effects of that 
thread; i.e., you aren't getting transactions for free.  Which isn't to 
say you can't build a transactional system on top of it.

> 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.  
Look at
  mlton.cvs.HEAD/basis-library/mlton/cont.sml
for how SML/NJ style continuations are build.  What you are looking for 
are the Primitive.Thread.{copy,copyCurrent} functions.  What you would 
want to do is find some way to lift these (internal,private) operations 
through the 
  mlton.cvs.HEAD/basis-library/mlton/thread.sml
implementation to provide a (public,external) operation to add to 
MLTON_THREAD:
  val copy : 'a t -> 'a t
which would do the work of copying the thread.  It may actually be easier 
to produce
  val copy : 'a t -> ('a t * 'a t)
whereby you destroy the incoming thread in order to produce the two 
outgoing threads.  Getting this right might be a little tricky.  Note that 
copying a thread (no matter how you do it) will take time proportional to 
the size of the thread.

Once you had MLton.Thread.copy, then you could use that in the CML 
scheduler code to make your copy.