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

FWIW, here's what worked:

  - A synchronous command channel
  - An asynchronous result channel
  - Raising errors only on the GUI thread

Having one asynchronous channel for commands and results was bad, as it 
was too easy for the GUI thread to read its own commands before the 
renderer could get and process them. Caused weird errors. Raising errors 
on the renderer threads killed their command loops.

Neil T

On 08/24/2011 04:48 PM, Jay McCarthy wrote:
> async-channel-put is the one that doesn't block
>
> Sent from my iPhone
>
> On 2011/08/24, at 16:42, Neil Toronto<neil.toronto at gmail.com>  wrote:
>
>> 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
>>>>
>> _________________________________________________
>> For list-related administrative tasks:
>> http://lists.racket-lang.org/listinfo/users