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

On 08/24/2011 06:07 PM, Robby Findler wrote:
> What is "the GUI thread"? Do you mean the DrRacket's eventspace
> handler thread, or the user's eventspace handler thread?

I didn't even know there was a difference until you brought it up. 
Should I be concerned about it?

Presumably, it's the eventspace handler thread that handles mouse events 
in snips that are displayed in the REPL or an editor.

> Did you use a kill-safe async channel? What do you do when the user's
> side gets killed and the requests pile up?

I don't know whether it's kill-safe. Are the ones in 
racket/async-channel kill-safe?

I did ensure that the protocol I implemented over the channels doesn't 
loop, so that unreachable threads will eventually block on a channel-get 
and get garbage-collected.

I think I'm okay WRT piled-up requests. The requests are *always* 
generated by user action. I have a timer to periodically check for when 
rendering is done so the event thread can keep processing mouse movement 
during rendering, which keeps mouse events from piling up during a slow 
render. But that doesn't generate any new requests - it just sets a flag.

I could probably do without the timer, somehow.

> You might try a program like this:
>
>    #lang racket/gui
>    (thread (lambda () (sleep (random 10)) (custodian-shutdown-all)))
>    ... produce one of the snips ...
>
> and see if you can get things to crash.

If it does crash, does that mean I did something wrong?

Neil T