Proposal: Add newUniqueSTM to Data.Unique
marlowsd at gmail.com
Fri Apr 27 17:50:09 CEST 2012
On 27/04/2012 15:58, Antoine Latter wrote:
> On Fri, Apr 27, 2012 at 5:24 AM, Simon Marlow<marlowsd at gmail.com> wrote:
>> 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
>> 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
> With this one, couldn't you divide the value space between the two?
> The IORef could get the even uniques, the TVar the odd?
That's a good idea.
>> 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
> Urk. What would it do inside a transaction, where the transaction
> creates a new unique with the STM API?
I presume you mean if it was called inside unsafePerformIO inside a
transaction: then it would cause the enclosing transaction to abort at
commit time. So you could shoot yourself in the foot by writing a
transaction that called out to a library that happened to use
unsafePerformIO.newUnique internally. So I retract my wild and crazy
> I don't know much about STM
> internals, so maybe it's easy to have 'atomicModifyTVar' sometimes
> latch onto the lexical transaction and sometimes not.
More information about the Libraries