Bugs in SampleVar and an API proposal
Bas van Dijk
v.dijk.bas at gmail.com
Thu Mar 18 13:04:21 EDT 2010
I was browsing over the code of Control.Concurrent.SampleVar and
noticed the same kind of bugs I also discovered yesterday in
* Throwing an asynchronous exception at the right time can make the
state of a SampleVar inconsistent which can cause a dead-lock.
* Numeric expressions are put in a MVar lazily which can cause a space leak.
The attached patch bundle contains a patch that fixes them both.
The bundle also contains another patch which changes the API of
Control.Concurrent.SampleVar. So this patch has to go through the
library submission procedure.
I propose making SampleVar an abstract (new)type instead of a type synonym.
* Users can not "screw up" the internal state like they can do now.
* We can define instances for SampleVars without using the
TypeSynonymInstances language extension. (This is actually the reason
I bumped into the type synonym nature of SampleVars. I'm making a
small library that defines some classes and I couldn't make SampleVar
instances for them)
* Potentially breaks existing code. However if it breaks your code you
are probably touching the internals which you shouldn't do anyway.
Discussion period: 1 week (Because I think this is a no-brainer)
Note I didn't derive an instance for Typeable for the SampleVar
newtype. This should be done, but I don't know the proper way
(manually, LANGUAGE DeriveDataTypeable or
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 32975 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20100318/ce0a5cf9/samplevar-0001.obj
More information about the Libraries