If the conclusion is that there's a bug here, could someone distil the example into a ticket?
Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]] On Behalf Of Ben | Gamari | Sent: 23 November 2017 15:20 | To: Yuras Shumovich <[email protected]>; ghc-devs <ghc- | [email protected]> | Subject: Re: Can strict ST break referential transparency? | | Yuras Shumovich <[email protected]> writes: | | > Hello, | > | Hello, | | Sorry for the late reply; this required a bit of reflection. The | invariants surrounding the suspension of ST computations is a rather | delicate and poorly documented area. | | I believe the asynchronous exception case which you point out is | precisely #13615. The solution there was, as David suggests, ensure that | no resulting thunk could be entered more than once by a very strict | blackholing protocol. Note that this isn't normal "eager" blackholing | protocol, which still might allow multiple entrancy. It's rather a more | strict variant, requiring two atomic operations. | | I can't be certain that there aren't more cases like this, but I suspect | not since most asynchronous suspensions where the resulting thunk might | "leak" back into the program go through the raiseAsync codepath that was | fixed in #13615. | | Cheers, | | - ben _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
