Proposal: add new forms of unsafePerformIO and
john at repetae.net
Fri Feb 22 07:19:36 EST 2008
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 Meacham - ⑆repetae.net⑆john⑈
More information about the Libraries