opt out of accursedUnutterablePerformIO

[David Feuer]

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" <ben at smart-cactus.org> wrote:

> Ben Franksen <ben.franksen at online.de> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180304/820d2c54/attachment.html>