> Marcin 'Qrczak' Kowalczyk wrote:
> > MVars should be simple. They are building blocks for more complex
> > things.
> I completely agree. But _if_ it should happen that my proposal could
> be implemented without making anything else more complicated,
> it would be
> the most logical new primitive. If not, then don't do it.
The only way I can see to do this is to add a lock field to the MVar. And
since this lock would look very much like another MVar, you may as well just
use another MVar to lock it (after all, that adds exactly zero extra
complication to the system :-).
> I suppose it is pretty certain that tryEmptyMVar can be
> implemented without
> making anything else more complicated. My only reservation
> about it is that
> there are probably other primitives for which there is an
> equally strong
> case. Perhaps the whole issue of what primitives MVars
> should have ought
> to be thought through again, rather than simply adding new
> primitives on
> demand.
Well, MVars have so far stood up to a great deal. IMO they have a
remarkably high usefulness to complication ratio.
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
3. 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.
BTW, I recently changed the MVar semantics in a subtle way:
- if takeMVar is blocked on an MVar that will never
become full, it may raise the BlockedOnDeadMVar
exception.
An MVar that can never become full can be detected by the garbage collector
- i.e. if the thread executing the takeMVar has the only pointer to that
MVar.
The rationale is that a thread should never just "go away" without getting a
chance to clean up after itself (this was the case before; the thread could
just be garbage collected).
Cheers,
Simon
