change to MLton.World.saveThread

[Stephen Weeks]

> My  notion  would  be  that  there  would be NO option to allow the resulting
> executable to go back to the `original' world.  It can ONLY restart the heap.
> The  point  is  that  one  might  do  fancy multi-staged worlds, and then the
> question would be why single  out  the  `original'  world.   It  is  just  as
> legitimate to want to go part way back.
> 
> One  disadvantage  of  this  (I think it is minor) is that the original a.out
> file is replicated in the saved world.  I view this as a very minor loss.  It
> is  only a concern if you want to go back (and, I suppose, for the transitory
> requirement of disk space).
> 
> Does this seem useful to people?  Is the change OK?

The change doesn't bother me, because I always have the original a.out if I want
to go back to the original world.

I haven't really run across uses for it, but I might try to use it sometime to
implement persistent state in a web server cgi program.

Shouldn't it be possible for us to allow users to do either -- i.e. have one
executable with lots of world (i.e. the current way) or have the executable
copied per world?