> Where I come from, that's called a race condition :-) We shouldn't change
> the semantics because it's possible to write broken programs using the
> existing semantics.
Where I come from, race conditions are not welcome in programs, only on
race courses:-) The point is that the semantics causes programs to be broken
*by default*, and that they have to be fixed (at least by handling the
exceptions, better by proving some statements about the dynamic behaviour
of a concurrent, dynamically evolving, asynchronous, higher-order, .. CH
program).
That it is quite possible to write programs that are not broken in spite of
the existing semantics doesn't mean that the semantics shouldn't be changed.
> It turns out that in a large number of cases, the existing MVar semantics
> is sufficient (and more efficient than using one of the abstractions).
Interesting. But also more reason to think about the defaults (if they are
not used from within safe abstractions).
Btw, does a distributed implementation of CH exist already?
Cheers,
Claus
