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 <[email protected]>wrote: > > > > On Thu, Mar 14, 2013 at 11:57 AM, Neil Toronto <[email protected]>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 > >
____________________ Racket Users list: http://lists.racket-lang.org/users
