At Sat, 10 Jul 2010 20:45:29 +0000, Taylor R Campbell wrote: > Using `dynamic-wind' turns out not to be enough if you have with > multiple threads: > > (GUI) (...) (...) > | | | > (button push) (B) (C) > | > (A) > > A `dynamic-wind' post-thunk there could prevent applying the > continuation `B' at `A', so you won't lose the GUI loop. For > applying `A' at `B', however, a guard in a `dynamic-wind' pre-thunk > may be too late; the GUI loop would be duplicated before the > pre-thunk could complain. > > I don't understand this last clause, that the GUI loop would be > duplicated before the pre-thunk could complain. Are you worried that > throwing into A will trigger DYNAMIC-WIND entrance procedures up in > the `(GUI)' frames that shouldn't be run more than once? If so, can't > those detect being run more than once and signal an error, as you > suggested below in the setup code?
If GUI has `dynamic-wind's inside, it seems more likely that it could deal with restarts --- or, yes, at least detect and prevent them. I was more concerned with what happens when the pre-thunk at `A' discovers a problem. If it raises an exception at that point, then the GUI will see the escape and may attempt clean-up actions that crash. I guess "too late" in this case is tied up with my view that libraries often will include escape-handling code without restart-handling code (and that it should be ok for them to be written that way). > To help library implementers, a continuation barrier is installed just > before before an exception handler is called. That way, if it is > possible for an exception to be raised, the implementer of `L-1' and > `L-2' can just use `with-handlers' to clean up, instead of having to > worry about jumps into the library. > > Can you be more specific about where continuation barriers are placed? > I just tried jumping about inside and outside handled extents and the > handlers themselves, and didn't hit any continuation barriers: > > ((call-with-current-continuation > (lambda (outside) > (lambda () > (with-handlers > ((continuation? > (lambda (inside) > ((call-with-current-continuation > (lambda (handler) > (outside > (lambda () > (handler > (lambda () (inside (lambda () 0)))))))))))) > (list 1 ((call-with-current-continuation raise)))))))) > ;Value: (1 0) The `with-handlers' form escapes before applying a handler procedure. To install an exception handler that is called in the dynamic extent of `raise', use `call-with-exception-handler'. > I've just pushed a change to Racket to use the "rnrs" trick > internally. Since the trick is implemented within the run-time system, > it can also hide the continuation-mark difference. In fact, given the > continuation machinery that we developed a couple of years ago, the > change was pretty easy; I just hadn't thought about it enough. > > So can full continuations now be used to exit across continuation > barriers just like exit-only continuations and prompt aborts, Yes. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
