Proposal: Add newUniqueSTM to Data.Unique
marlowsd at gmail.com
Mon Apr 16 17:21:31 CEST 2012
On 10/04/2012 19:56, Edward Kmett wrote:
> 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
> The only vote during the discussion period was a +1 for reverting to the
Thanks for the reminder. I'll add newUniqueSTM, since I don't like the
idea of people using unsafeIOToSTM and don't want to encourage its use.
> On Wed, Jan 19, 2011 at 2:45 PM, Edward Kmett <ekmett at gmail.com
> <mailto: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
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries