[MLton] Non-exhaustive exn fn match

[Wesley W. Terpstra]

Ok, I've tried to hold my tongue, but ... :-)

On Tue, Jul 19, 2005 at 04:33:53AM +0300, Vesa Karvonen wrote:
> Perhaps I wasn't clear enough. What I was thinking about is that the
> implementation of the UT would either A) use some critical section procedure
> (like MLton.Thread.atomically), which can reduce portability, or B) not use a
> critical section, which means that the code wouldn't be thread safe. Either
> way one has some interesting times ahead (portability problems / nasty bug).

You can always use cooperative threading, in which case this is not a
problem. There are are many reasons (maintainability, speed, ...) to use
cooperative instead of preemptive threads.

To answer Stephen's comment some messages ago: this is the primary
difference between my thread package and CML. CML is preemptive and 
thus has to spend effort on an API for synchronization.

My threads context switch only when executing blocking I/O.
Their sole purpose is to simplify scalable internet server design.

> I wasn't really referring to any particular thread implementation. The
> cost would increase significantly if the thread implementation supports
> true parallelism and you actually have multiple processors.

If you want multiple processors executing threads, of course, you need
atomicity (or process-based parallelism as was discussed a week ago).

> > > It is much better to just avoid unnecessary shared state, IMHO.

If it is unnecessary, then I completely agree.

-- 
Wesley W. Terpstra