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

On Wed, Aug 24, 2011 at 10:19 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
> 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.

If it is the DrRacket REPL then that's the DrRacket eventspace handler thread.

>> 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?

If it wedges DrRacket, then yes. If you crash and there is a
reasonable error message, etc., then no.

Robby