[plt-scheme] escape continuations and mred callback

On Oct 7, 2006, at 10:27 PM, pedro pinto wrote:

> OK, I finally see what you mean, I assumed that when I called (send  
> dialog show #t), the program would enter a loop that plucks  
> messages out of the dialog event queue and dispatches them  
> *synchronously* to the appropriate callbacks. A small test I did  
> indicates that no event dispatch occurs while a callback is  
> beinghandled, so at least the dispatch does appear synchronous. So,  
> in theory at least, for my particular example, I think an escape  
> continuation could still take me out of a callback and back into my  
> own code.
>
> As you point out however in the non-modal case, there must be a  
> message loop, or watch dog,  running on another process and in that  
> case I suppose invoking the escape continuation would replace the  
> watch dog stack with the one on my original process, and, since I  
> suspect there is only one watch dog for all the windows in the  
> application, kill all UI updates. I can see why there would be need  
> for a continuation barrier.
>
> Does this make any sense, or I am totally of base here?

You got it.

Robby explains what happens in the modal case but that's just icing  
on the cake. -- Matthias




>
> Thank you for your patience,
>
> -pp
>
>
> On 10/7/06, Matthias Felleisen < matthias at ccs.neu.edu> wrote:
>
> No you didn't. A callback doesn't return and can't return. It is an
> asynchronous call from somewhere deep inside when an event occurs. In
> a sense, it is run in concurrently to the rest of the program. In
> your special case, it was waiting (due to the modal dialog) and one
> could argue that there is a sequential flow of control. But that's
> just a special case.
>
> So, in general, some concurrent process watches the "world" and waits
> for events to happen. When they do happen, it checks whether you want
> to know about it. This watch dog finds out that you have installed a
> callback and calls. If you raise an exception, the exception erases
> the control stack of this call and everything around it. In other
> words, it stops the execution of the watchdog process. Now your own
> process is spared. After all, there is no connection between the
> watchdog and your application.
>
> This has little to do with the fearsome first-class continuation
> objects in Scheme but everything with "GUI concurrency" and
> "exceptional flow of control."
>
> Since callbacks can't return, they have void as a return type. You
> are therefore forced to communicate all results and values across
> this "void wall" via side effects.
>
> ;; ---
>
> If you really want to dig deep: all this is the fundamental flaw of
> call-back based programming. It's the dominant and efficient model. I
> sure wish, however, we could come up with something better.
>
> -- Matthias
>
>
>