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

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: evil-snip.rkt
URL: <http://lists.racket-lang.org/users/archive/attachments/20110824/b76328e1/attachment.ksh>