contification paper

[Matthew Fluet]

> I guess the thing to do is to put a little wrapper around Time.- within
> control.sml that checks before calling Time.-, and returns 0 if its first arg is 
> < its second arg (probably also should print a warning message for now so we can 
> confirm that is the problem).

I came to the same conclusion, although I just wrote a wrapper for Time.-
that handles the Time exception and returns 0.  I'll add in the warning
message as well and see what happens.

> For real times?  I would say no way.  I suppose it might happen on a machine
> with more than 1 CPU since I think there are some hacks using the CPU time-st$
> register, and they aren't precisely synchronized with 2 CPUs.  Even then I
> would be very very surprised if it actually happened.

Well, it was occuring on a dual-proc PIII system.  And it is repeatable; I
was getting it about 1/5 of the time on repeatedly doing 
mlton -v3 barnes-hut.sml
Looking at the log, it also occured on a number of other benchmarks.  It's
certainly something odd, because it was being raised at different points
-- sometimes during cps simplify, sometimes during codegen, etc.

> I guess it could also happen if you changed the date by hand.  NNTP, the netw$
> time daemon shouldn't cause this to happen since it speeds up or slows down t$
> clock, it doesn't reset it.

That machine isn't networked at all.