Proposal: Add newUniqueSTM to Data.Unique
aslatter at gmail.com
Fri Apr 27 16:58:39 CEST 2012
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?
> 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 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