[racket] plot-frame does not wait at end of process

On Thu, Mar 14, 2013 at 11:57 AM, Neil Toronto <neil.toronto at gmail.com>wrote:

> On 03/11/2013 02:51 PM, Eli Barzilay wrote:
>
>> A few minutes ago, Robby Findler wrote:
>>
>>> Michael Wilber kindly sent me the link:
>>>
>>>    http://lists.racket-lang.org/**users/archive/2012-April/**051485.html<http://lists.racket-lang.org/users/archive/2012-April/051485.html>
>>>
>>
>> (Ah, sorry, I thought that you knew where the discussion was...)
>>
>>
>>  and I think that this is not really a good argument for changing the
>>> default behavior. A keyword argument that says "create a new
>>> eventspace" seems okay, but the docs should explain that this is
>>> multi-threading, and if you were to invoke methods of the plot frame
>>> without first going to the new eventspace (via queue-callback or
>>> something like that), then you'll probably get bad behavior.
>>>
>>
>> Sounds like exactly what I'm asking for: a sensible default that works
>> naively, and if the new eventspace is really useful, then do that with
>> a non-default keyword.
>>
>
> Thanks for hashing all this out without me. :)
>
> Do we have a consensus? Is it this?
>
>  * Go back to default frame behavior (i.e. plot frames use main GUI
>    thread eventspace)
>
>  * Add #:new-thread? keyword argument (or a more suggestive name) to
>    `plot*' functions that can return or display a frame
>
>  * Add `plot-new-thread?' parameter for #:new-thread? default
>
> An alternative to the above is adding a `wait-for-plots' procedure that
> syncs on all the plot frames' eventspaces. But then this from Robby
> suggests separate eventspaces are dangerous in the first place:
>
>
> > if you were to invoke methods of the plot frame without first going
> > to the new eventspace (via queue-callback or something like that), then
> > you'll probably get bad behavior.
>
> I didn't know that.
>
>
FWIW, I say "probably" here in the sense that I expect those methods
manipulate internal state and that they aren't thread safe. You may have
designed them to be, tho.

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130314/96e4ea19/attachment.html>