Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: > | Now that is very interesting, and certainly not something I would have > | expected! Why would asynchronous exceptions need to capture any portion of > | the stack? Exceptions obviously trigger stack unwinding, so I assumed the > | “abort to the current prompt” part of my implementation would already > | exist, but not the “capture a slice of the stack” part. Could you say a > | little more about this, or point me to some relevant code? > > Suppose a thread happens to be evaluating a pure thunk for (factorial 200). > Then it gets an asynchronous exception from another thread. That asynch exn > is nothing to do with (factorial 200). So we could either > > A. revert the thunk to (factorial 200), abandoning all > the work done so far, or > B. capture the stack and attach it to the thunk, so that ie any other > thread enters that thunk, it'll just run that stack. > > Now (A) means that every thunk has to be revertible, which means keeping its > original free variables, which leads to space leaks. And extra work to avoid > losing any info you need for reversion. Extra work is painful; we want to > put all of the extra work on the asynch exn. > > So we do (B). > > See Section 8 of "Asynchronous exceptions in Haskell". > https://www.microsoft.com/en-us/research/publication/asynchronous-exceptions-haskell-3/ > > And "An implementation of resumable black holes" (Reid). > https://alastairreid.github.io/papers/IFL_98/ > > This stack-freezing stuff is definitely implemented. I'm not quite > sure where, but I'm cc'ing Simon Marlow who can point you at it. > For the record, runtime system captures the stack state in an AP_STACK closure. This is done in rts/RaiseAsync.c:raiseAsync and some of this is described in the comment attached to that function.
As Simon PJ points out, this is all very tricky stuff, especially in a concurrent context. If you make any changes in this area do be sure to keep in mind the considerations described in Note [AP_STACKs must be eagerly blackholed], which arose out of the very-nast #13615. Cheers and good luck! - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
