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

Oh! I've been laboring under the delusion that channel-put doesn't 
block, only channel-get. That would explain a lot.

I'll try some of this kill safety stuff. Where's the paper?

Neil T

On 08/24/2011 03:47 PM, Robby Findler wrote:
> 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
>>