Asynchronous exceptions and laziness bugs in
Data.Unique.newUnique
Simon Marlow
marlowsd at gmail.com
Thu Mar 18 06:45:55 EDT 2010
On 17/03/2010 15:49, Bas van Dijk wrote:
> Hello,
>
> I just browsed over the source of Data.Unique.newUnique[1]:
>
> newUnique :: IO Unique
> newUnique = do
> val<- takeMVar uniqSource
> let next = val+1
> putMVar uniqSource next
> return (Unique next)
>
> I think asynchronous exceptions should be blocked. Currently if an
> asynchronous exception is thrown after taking the MVar, putMVar is not
> executed anymore, leaving the MVar in the empty state. A subsequent
> call to newUnique will then dead-lock when it tries to take the MVar.
>
> Another problem is the laziness of 'next'. When you put 'next' in the
> MVar you actually put the thunk 'val+1' not an Integer in WHNF. When
> you create say a million uniques the last unique will be a very large
> thunk like 0+1+1...+1. Forcing that thunk (when you print the hash of
> the unique for example) will probably overflow your stack.
>
> The attached patch adds the necessary block and strictly evaluates the
> next unique value.
Thanks, I'm actually going to change this to use STM as it does a better
job than MVars in this case.
Cheers,
Simon
More information about the Libraries
mailing list