Proposal: Add newUniqueSTM to Data.Unique

[Simon Marlow]

On 17/04/2012 15:56, Edward Kmett wrote:
> 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.

So the options are:

  1. Use STM; provide newUniqueSTM;
     newUnique will not work inside unsafePerformIO

  2. Use atomicModifyIORef;
     no way to generate uniques in STM

  3. Use atomicModifyIORef; provide a separate STM version;
     Uniques generated by newUnique and newUniqueSTM might clash

What would you like to do?  None of the options are perfect.

Hmm, thinking aloud here, I suppose it *might* be possible to add

   atomicModifyTVar :: TVar a -> (a -> (a,b)) -> IO b

that would not use a full transaction internally, and would work inside 
unsafePerformIO.

Cheers,
	Simon


> 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
>>