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

Also: I don't think that you need a parameter for this default. the
current-eventspace parameter would already do this job.

Robby


On Thu, Mar 14, 2013 at 1:11 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

>
>
>
> 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/d0d4da99/attachment-0001.html>