time bug

[Matthew Fluet]

> > > Makes sense.  Another solution would be to have a single routine that returns
> > > times, like:
> > > 
> > >    val MLton.ProcEnv.times: unit -> {elapsed: Time.time,
> > > 				     cstime: Time.time,
> > > 				     cutime: Time.time,
> > > 				     gc: Time.time,
> > > 				     stime: Time.time,
> > > 				     utime: Time.time}
> > 
> > Wouldn't this suffer from the same problem?  Either we query
> > gcState.gcTime before or after a call to the times() "C" function.  We
> > can't write a gc.c function that returns that whole structure and import
> > it as a _ffi.  I suppose we could set it up in the same way Posix/Tms.c is
> > implemented; a side effecting _ffi call to atomically store all of the
> > sub-fields and then individually get each one.
> 
> Yep.  That's what I had in mind.  That way, intervening gc calls don't matter.
> 

O.k.  But then, related to one of my other comments, you could only
reasonably have a function:

val MLton.ProcEnv.times: unit -> {utime: Time.time,
                                  stime: Time.time,
                                  gc: Time.time}

because with getrusage you can only get self or children time with a call.
And I also think that for real "apples-to-apples" comparision, you would
want either

val MLton.ProcEnv.times: unit -> {total: {utime: Time.time,
                                          stime: Time.time},
                                  gc: {utime: Time.time,
                                       stime: Time.time}}

or

val MLton.ProcEnv.times: unit -> {total: Time.time,
                                  gc: Time.time}

That is, either do all of the aggregation in C or in ML.  My vote would be
for the first option, because it is a little more precise, even though it
will make gc.c a little more complicated.