Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO

[John Meacham]

On Fri, Feb 22, 2008 at 09:41:46AM +0000, Simon Marlow wrote:
>> 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.

Also, unsafePerformIO is in the FFI specification, even though it isn't
fully specified with respect to multi-processing I think there was some
expectations of what 'unsafePerformIO' meant, for better or worse.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈