[MLton] CML

[Matthew Fluet]

> > (Although, I think this is a design problem that can be easily fixed.  The
> > transaction id datatype is always paired with some data (usually a CML
> > thread and maybe some associated data) that predicates as being either
> > still a valid transaction or a cancelled transaction.  If we made the
> > trans_id datatype an essentially an 'a option ref, then the paired data
> > could be held within the trans_id and would automatically become
> > unreachable when the transaction is cancelled.)
>
> To make sure I understand, since the same trans_id can be paired with
> lots of different data, this approach requires keeping a list of all
> pairs associated with the trans_id so that when it is cancelled, you
> can walk the list and clear all the option refs.  Heck, at that point,
> why not remove the cancelled pair from the queue it is in?  This would
> require more mutable queues, but that's not too hard.

That sounds correct.  I was forgetting that the same trans_id is paired
with different data for each of the blocked events.

In any case, though, MLton is better off, because threads go dead and
won't keep extraneous stuff alive.