[plt-scheme] escape continuations and mred callback

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?

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20061007/4882b838/attachment.html>