Proposal: Add newUniqueSTM to Data.Unique

[Edward Kmett]

Using the newUniqueSTM approach, while it fixes the issue of obtaining Uniques from STM will still mean that there is no way to unsafePerformIO or unsafeInterleaveIO anything that would get you a newUnique without forking a whole thread, and getting it atomically there, no? 

That concern was why the discussion last time had turned toward reverting to the previous IORef version, which is safe under a wider array of conditions.

Sent from my iPad

On Apr 16, 2012, at 11:21 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> 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
>> unexpectedly.
>> 
>> The only vote during the discussion period was a +1 for reverting to the
>> IORef.
> 
> 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.
> 
> Cheers,    
>    Simon
> 
> 
>> -Edward
>> 
>> 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
>> http://www.haskell.org/mailman/listinfo/libraries
>