[racket] DrRacket locking up on errors in non-GUI worker threads

It seems like the exception stops the render-thread from doing a
channel-get so the channel-put that drracket does blocks forever.
Right?

Have you read the kill safety paper? I think that you'd need to use a
pattern like that to make this really work. After all, the user's
program can be terminated at any time and the repl might still contain
those snips that are trying to draw themselves without someone to talk
to on the other side.

Assuming you've read that paper, then I think the thing you want to do
is set up a thread that just listens for requests for user-side state
and answers them. This thread will be on the user's thread and subject
to random killing (so use the kill safety stuff to deal with that).
Then, do everything else on the DrRacket side where you're safe from
killing.

Robby

On Wed, Aug 24, 2011 at 4:27 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
> I can't keep DrRacket from locking up whenever an exception is raised on a
> non-GUI thread that does work in response to a channel-put from the GUI
> thread.
>
> I've attached simplified code for a custom snip% and its non-GUI render
> thread. The code contains commented-out attempts at solving the lock-up
> problem and comments underneath that say what the solutions actually did.
>
> Details:
>
> I've got a descendant of image-snip% that needs to be updated periodically.
> Rendering the update depends on a zillion parameters, which I MUST get from
> the program thread, not the GUI thread. If I got parameters from the GUI
> thread, setting parameters in the program thread before creating the snip
> wouldn't affect later rendering, which would be bad.
>
> To ensure that rendering uses parameters from the program thread, I start a
> rendering thread upon creating the snip. The rendering thread inherits the
> program thread's current parameters.
>
> When the snip updates, it uses channel-put on the GUI thread to tell the
> rendering thread to render. When the rendering thread finishes, it uses
> channel-put to return the result.
>
> When the snip is copied, the copy needs a new rendering thread. I have the
> old rendering thread create a new rendering thread for the copy. The new
> thread's parameters are what the program thread's parameters were when the
> original snip was created.
>
> This all works just great, no problems.
>
> Until there's an error. Then I can't keep this silly tower of threads from
> locking up DrRacket, even if I catch the errors and silently ignore them!
>
> Help, please?
>
> Neil T
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>