Proposal: Add newUniqueSTM to Data.Unique

[Edward Kmett]

I was wondering if it would be possible to resolve this issue one way or
the other. The discussion trailed off last year. Ed Yang proposed switching
back to an IORef. and Bas benchmarked things showing a slight benefit to
the IORef version.

As it stands unsafePerformIO newUnique expands to unsafePerformIO $
atomically $ do ...

which is unsound and can cause the runtime to crash out on you rather
unexpectedly.

The only vote during the discussion period was a +1 for reverting to the
IORef.

-Edward

On Wed, Jan 19, 2011 at 2:45 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Data.Unique's newUnique uses atomically internally to update a
> TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a
> Unique within an STM transaction blows you sky high.
>
> The proposal is to split the definition of newUnique into:
>
> newUnique = atomically newUniqueSTM
>
> and expose newUniqueSTM.
>
> Alternately, since bug #3838 has been resolved, we could revert to using
> an IORef, which would avoid the wart of having us have an overtly IO action
> detonate because of an internal implementation detail of using STM.
>
> Since, there are two paths forward, I haven't put forward a patch, but
> wanted to open a discussion.
>
> Discussion Period: 2 weeks.
>
> -Edward Kmett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120410/a44a8eb0/attachment.htm>