[Haskell-cafe] Stack overflow

[Krzysztof Skrzętnicki]

On Thu, May 28, 2009 at 14:41, Bertram Felgenhauer
<bertram.felgenhauer at googlemail.com> wrote:
> Krzysztof Skrzętnicki wrote:
>> 2009/5/27 Bertram Felgenhauer <bertram.felgenhauer at googlemail.com>:
>> > I wrote:
>> >> Krzysztof Skrzętnicki wrote:
>> >>> The code for modifying the counter:
>> >>> (\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,())))
>> >>
>> >> atomicModifyIORef does not force the new value of the IORef.
>> >> If the previous contents of the IORef is x, the new contents
>> >> will be a thunk,
>> >>
>> >>   (\ cnt -> (cntMsg cnt msg,())) x
>> >
>> > Sorry, it's slightly worse than that. The contents becomes
>> >
>> >    sel_0 (\ cnt -> (cntMsg cnt msg, ())) x
>> >
>> > where sel_0 is basically an RTS internal version of fst.
>> >
>> > Instead of reading the new value of the IORef, you could also force the
>> > old one:
>> >
>> >    atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg, msg)) >>= (return $!)
>> >
>>
>> Thanks for the tip, although it seems tricky to get it right. I wonder
>> why there is no strict version of atomicModifyIORef?
>
> Something like this?
>
> -- | Stricter version of 'atomicModifyIORef', which prevents building
> --   up huge thunks in the 'IORef' due to repeated modification.
> --   Unlike 'atomicModifyIORef', 'atomicModifyIORef'' may block.
> atomicModifyIORef' :: IORef a -> (a -> (a, b)) -> IO b
> atomicModifyIORef' ioref f = do
>    res <- atomicModifyIORef ioref f
>    new <- readIORef ioref
>    new `seq` return res
>
> (The step that may block is forcing the new value - if another thread is
> already evaluating part of the thunk, the currently executing thread
> will block, waiting for the other thread to finish.)
>
>> Dually there might be a strict version of IORef datatype.
>
> One interesting feature of atomicModifyIORef is that its implementation
> is lock-free, and never blocks (which affects exception handling):
> replacing the old value by the new value is done with compare-and-swap
> operation in a tight loop. Each iteration executes very quickly because
> all it does is replace the reference to the old value in the new thunk.
>
> With a strict IORef, the time window between reading the old value and
> storing the new value would become arbitrarily large, because you'd have
> to force the new value before exchanging it with the old value. So a
> reasonable implementation would have to use locks instead, I think,
> making atomicModifyIORef more expensive, and less useful in contexts
> that block exceptions.

We may as well drop the 'atomic' keyword and provide a warning about
possible blocking of thread. The end user may forkIO the modification
if he wants to.

I modified the code as follows, it works now:
(\ msg -> atomicModifyIORef ioref (\ cnt -> (cntMsg cnt msg,cnt)) >>=
(return $!))

Thank you all for your help!

Best regards

Christopher Skrzętnicki