MLton.RUsage.ru

[Stephen Weeks]

> In  most C code, establishing a critical section has a sufficiently high cost
> that it will dominate in the case of just copying a few values.   This  might
> not  be  the  case for MLton, but you still have to, at the minimum, set some
> global to enter the critical section and clear  some  global,  probably  also
> doing  a test to see if there was an interrupt, on exit.

Unfortunately, right now atomicBegin and atomicEnd are _ffi's (and hence
procedure calls), but all they do is an increment or decrement.  They will be
turned into _prim's at some point.

> I guess I don't see
> the advantage.  Given that the types are all int's here, you  can  just  call
> MLton.RUsage.ru  with  an array of ints as an argument.  There is no escaping
> that a copy has to happen from the C structure to the MLton one.  This way it
> is written in MLton, and is very clean.

The copy will be done in MLton with my approach too.  The difference between
yours and mine that I see is that yours ensures thread safety by doing an
allocation at each call and mine ensures thread safety with a critical section.
I suspect mine is faster.  Both have to worry about threads (after all, you are
careful to do the allocation once per call instead of just once).

> As to the threads, I always worry about later finding all the places where an
> assumption was made  about  things  like  basic  blocks  being  automatically
> atomic.

I agree, and don't want to make that assumption, which is why I propose using a
critical section (in a future release).