MLton.RUsage.ru

[Henry Cejtin]

In making the Red Hat 6.0 RPMs I had to do the `cross' compile using an older
MLton.  I used the trick you suggested, or having  the  old  MLton  create  a
world.mlton  from  the  new  sources, but I also had to link it with a C file
that defined the MLton_RUsage_* entry points.  In doing this I was surprised,
but  I  remember this was discussed at the time, by the method used of having
static variables that MLton.Rusage.ru  sets  and  other  routines  to  access
these.  Why do it this way instead of just returning all the results from the
ru call (by just passing it a bunch of  int  ref's).   Not  that  performance
matters much here, but it just seems nicer.

Either way, what, if any thing, do you do about thread safety.  Not that I am
a great fan of threads.  If you use the method I suggest, and you create  the
ref's on each call then there is no race and all is fine.  If you share ref's
between different calls, or use the current method (which is the  same  thing
but  with  the `ref's being the static C variables that ru fills in) then you
can be pimped by having some other thread clobber them after you have  filled
them in and before you read them.  I thought for a moment that this might not
be a disaster since you just get more recent information for  some  of  them,
but  that  isn't  really  true.  You might get, for instance, a GC time which
exceeds your total CPU time.

Like I said, I don't like threads, but for this case, allocating the ref's on
every  call isn't too high a price to pay I guess.  Either way, it seems like
a nicer interface than having to call all these  C  routines  to  essentially
copy  a  struct  over.  (Probably faster to, but who cares about that in this
case.)