local refs

[Matthew Fluet]

> Makes sense.  Actually, with my new changes, it is only
> Thread_copyCurrent that can cause escapes.  Hmmm ... I'm not so sure
> ... have a look at the only remaining use of Thread.current, which is
> in thread.sml.  Maybe it's OK here because the thread really is just
> being paused -- there is no implicit control flow.

I don't know.  See my previous e-mail -- I might have the intended
semantics of threads all wrong.  Currently, I'm thinking in SSA, so I'm
thinking of arbitrary uses of primitives in arbitrary SSA programs.
You're suggesting above that "this specific case is OK" because "this is
the only time/way it's used".

The way I'm thinking now, I'd say "no" to the above, because with
x = Thread_current, any Thread_copy(x) acts like Thread_copyCurrent.
The conservative approximation would be any use of Thread_current implies
that Thread_copy should be treated like Thread_copyCurrent.

The other aspect that is missing is atomicBegin/End, which really do
demark single-threaded portions of the program.  Of course, those are
FFI's, so I don't know how useful they are, but it would be trivial to
turn them into Prim.t's that are implemented as FFI's.