Matthew Fluet <fluet@CS.Cornell.EDU>
Thu, 8 Mar 2001 17:35:08 -0500 (EST)
> 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.