Re: opt out of accursedUnutterablePerformIO

For the record, the "public" version of runRW# is called unsafeDupablePerformIO. It would be a good idea to find out if it can be used throughout bytestring without a significant penalty. If so, that would eliminate a bunch of scary stuff. If not, it would be nice to understand why. On Mar 4, 2018 4:48 PM, "Ben Gamari" wrote:

Ben Franksen writes:

...

Am 04.03.2018 um 15:58 schrieb Ben Gamari:

...

I'm afraid it's not possible to provide the interfaces exposed by bytestring without some form of unsafety. Lazy IO alone requires unsafeInterleaveIO and the bytestring indexing operations require at very least unsafePerformIO since GHC treats access to foreign memory as an effect.

I am well aware of that.

...

accursedUnutterablePerformIO is an optimized form of unsafePerformIO which likely won't cause any issues that wouldn't otherwise manifest with plain unsafePerformIO. Consequently I am not sure it's worth providing a means to disable its usage.

I envy your confidence. The documentation mentions two bytestring commits that fix bugs by reverting accursedUnutterablePerformIO to unsafePerformIO. I guess this is plain evidence that there can in fact be "issues that wouldn't otherwise manifest with plain unsafePerformIO".

Ahh yes, I had forgotten that accursedUnutterablePerformIO is implemented directly in terms of realWorld#. This implementation is terribly bug-prone since floating can result in inappropriate sharing, as seen in the tickets referred to in the documentation.

However, GHC 8.0 and later offer a much safer primitive, runRW#, which can be used to implement things like accursedUnutterablePerformIO without fear of over-zealous simplification. I believe the issues pointed out in documentation could not have happened with an implementation built on runRW#. Moreover, I highly doubt that the switching to runRW# would incur any measurable performance penalty.

...

Anyway. Would you perchance have any idea what could possibly make a program work fine with the first version of linesPS and crash with the second one? I find this pretty scary and would like to understand it.

Indeed that is quite scary. The cause is not at all obvious. Do you have an isolated reproducer that you could share?

Cheers,

- Ben

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries