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