[MLton] cvs commit: MAIL: Initial port of CML from SML/NJ to MLton.

[Matthew Fluet]

> > This is an initial port of CML from SML/NJ to MLton.
>
> Excellent.
>
> > There was only one complicated transformation: blocking multiple base
> > events.
> ...
> > To accomplish the same effect in the MLton thread implemenation, we
> > have the following:
> >       datatype 'a status =
> > 	 ENABLED of {prio : int, doitFn : unit -> 'a}
> >        | BLOCKED of {transId : trans_id,
> > 		     cleanUp : unit -> unit,
> > 		     next : unit -> rdy_thread} -> 'a
> ...
> > I'm worried that this implementation might be a little expensive,
> > starting a new thread for each blocked event (when there are only
> > multiple blocked events in a synchronization group).  But, I don't
> > see another way of implementing this behavior in the MLton thread
> > model.

> I see that a blockFn typically (always?) does an atomicSwitch, which
> also creates a thread, so there are actually two thread creations per
> blockFn.

Well, atomicSwitch captures the current thread, as opposed to new, which
does a little more work to create a new thread.

> Since the blockFns need to do this so that they can put
> their thread in some appropriate queue, the only way out I can see
> would be to change the type of the queues that are involved to be
> queues of thunks that return threads instead of queues of threads.

Yeah, when I first encountered this problem, I thought something along
these lines might work.  But, I needed to get event.sml working fairly
early on in the port, and I went with the solution that I could get
working first, and seemed to have the least impact on the rest of CML.

Now that things are working and I'm more comfortable with how things are
put together, I'll come back and try this approach at some point.
Certainly, a few more thunks would be cheaper than more threads.