time bug

[Matthew Fluet]

> > I  would  definitely  vote for getrusage() over times().  My argument is that
> > the former is in seconds/microseconds while the latter depends on the  length
> > of  time  in  a  clock tick which is goofy.  This rounding problem could have
> > caused the problem as Matt said.
> 
> I agree, and have no objection to replacing all occurrences of times() with
> getrusage().  

Well, the only calls to times() in the basis are through
Posix.ProcEnv.times and through MLton.GC.gcTime.

But, I disagree that we can just replace all occurrences of times() with
getrusage().  First, (according to the man pages) getrusage() isn't POSIX
conforming, so it seems a little strange using it for the Posix structure.

Also, we would need to do two calls to getrusuage (one with SELF and one
with CHILDREN) to fully fill in the {elapsed, utime, stime, cutime,
cstime} record.  I haven't looked through of the source, but I suspect
that each call would be independent. 

> The basis library code will have to be changed a bit, either
> exporting getrusage and its "who" parameter, or by exporting two different
> getrusage calls.  The right thing is probably to expose the struct rlimit fields 
> via primitive accessors and do all the computation on the SML side.  That way,
> we can add more accessors as we need them.  Matthew? :-)

I guess we could add a MLton.RUsage structure with 

datatype who = SELF | CHILDREN
datatype timeval = {sec: int, usec: int}

val toTime: timeval -> Time.time
val rusage: who -> {utime: timeval, (* user time used *)
                    stime: timeval, (* system time used *),
                    ... (* whatever other fields we want *)}

I'd also be really tempted to change MLton.GC to have

datatype timeval = {sec: int, usec: int}
val toTime: timeval -> Time.time
val gcTime: unit -> {utime: timeval, stime: timeval}

and change gc.c to store all of it's internal time structures as 
struct time {timeval utime; timeval stime};
values.  Or, at the very least, have gcState store everything in terms of
microseconds, otherwise, I think we're still risking being subject to
rounding errors.