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

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