Wed, 5 May 2004 08:11:20 -0400 (EDT)
> > (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.