Proposal: add new forms of unsafePerformIO and
simonmarhaskell at gmail.com
Fri Feb 22 04:41:46 EST 2008
Stefan O'Rear wrote:
> On Thu, Feb 14, 2008 at 10:54:37AM +0000, Duncan Coutts wrote:
>> This version of 'unsafePerformIO' is slightly more efficient, because it
>> omits the check that the IO is only being performed by a single thread.
>> Hence, when you write 'unsafeDupablePerformIO', there is a possibility
>> that the IO action may be performed multiple times (on a
>> multiprocessor), and you should therefore ensure that it gives the same
>> results each time.
>> unsafeDupablePerformIO :: IO a -> a
>> TODO: Actually, unsafeDupableInterleaveIO is not yet documented,
>> that will have to be fixed.
>> unsafeDupableInterleaveIO :: IO a -> IO a
> I propose that unsafeDupablePerformIO be renamed to unsafePerformIO,
> since it satisfies all of the properties guaranteed of unsafePerformIO.
> GHC's unsafePerformIO guarantees more, and should be called
> unsafePerformIOAtMostOnce or something.
That's certainly a defensible position, but I'll present a counter-argument.
If you've managed to use unsafePerformIO in a way that works on a single
processor, then you will probably be tempted to assume that it will work on
a multiprocessor too. Currently unsafePerformIO tries to make that true
(although it's not foolproof, and it's quite expensive).
Look at all that stuff in the docs for unsafePeformIO about -fno-cse and
let-floating (I think it goes too far, in fact - if your use of
unsafePerformIO is that fragile then you're doing something wrong). If
unsafePerformIO was the dupable version by default, then all that goes out
of the window if you happen to be running with two threads on an SMP. And
if you're writing a library, you have to assume the worst and go for the
AtMOstOnce version - who would remember to do that?
Better for the default version to be safe in this respect, IMO. The bugs
we'd get from this would be really hard to track down.
More information about the Libraries