"Claus Reinke" <[EMAIL PROTECTED]> wrote,
> > There's still some discussion to be had on what putMVar should
> > do when presented with a full MVar. The options are
> >
> > 1. throw an exception (as now)
> > 2. block until the MVar is empty
> > 3. succeed, replacing the current value in the MVar
> > 4. succeed, adding the new value to a buffer in the MVar
> >
> > (1) is easy to implement. (2) is more convenient occasionally,
> > but can always be implemented with an extra MVar. (3) is also
> > more convenient in certain cases (imagine an MVar that held
> > mouse movement events), but again can be implemented with extra
> > MVars. (4) adds some complication to the MVar implementation.
>
> This is one aspect of the Concurrent Haskell design I have never
> been happy with - I would much prefer (2) over (1), the original
> CH paper also mentioned ordered (4a) and unordered buffering
> (4b). Here are some arguments for the discussion:
>
> a. Ease of implementation should never be the first argument;-)
In the case of basic functionality like the synchronisation
provided by MVars, ease of implementation and efficiency go
often hand in hand. For such a basic structure, efficiency
matters a lot.
> b. In contrast to other things, that can be built on top of the
> current MVars, (1) is not only inconvenient, but unsafe,
> unless (and in a sense even if, see (d)) you always protect
> each use of putMVar with an exception handler (do you?).
Whenever the program logic (in all possible schedules)
guarantees that an MVar is never written to a second time
before it is read at least once, there is no need for an
exception handler. Whenever the program logic does not give
that guarantee, you have to either use an exception handler
or establish this guarantee by using a second MVar.
This is like using partially defined functions. If you
define a function partially, you have to make sure that you
never call it with a value not in its domain; otherwise, you
get a runtime error, like with MVars.
Manuel
