MLton.RUsage.ru

[Stephen Weeks]

> 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.

I agree.  It does seem nicer.  Although, what I'd really like is some compiler
support for accessing C struct fields.

> 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.

Makes sense.  I think we're OK for now because thread switches don't happen in
the middle of basic blocks, and all those FFI calls to extract the fields will
be straightline code.

> 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.)

I like your way better, but I think an even better way may be to have a critical
section containing one ffi call to fill in the struct and a sequence of selects
using the aforementioned compiler support.