<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 11:57 AM, Neil Toronto <span dir="ltr">&lt;<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/11/2013 02:51 PM, Eli Barzilay wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A few minutes ago, Robby Findler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Michael Wilber kindly sent me the link:<br>
<br>
   <a href="http://lists.racket-lang.org/users/archive/2012-April/051485.html" target="_blank">http://lists.racket-lang.org/<u></u>users/archive/2012-April/<u></u>051485.html</a><br>
</blockquote>
<br>
(Ah, sorry, I thought that you knew where the discussion was...)<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and I think that this is not really a good argument for changing the<br>
default behavior. A keyword argument that says &quot;create a new<br>
eventspace&quot; seems okay, but the docs should explain that this is<br>
multi-threading, and if you were to invoke methods of the plot frame<br>
without first going to the new eventspace (via queue-callback or<br>
something like that), then you&#39;ll probably get bad behavior.<br>
</blockquote>
<br>
Sounds like exactly what I&#39;m asking for: a sensible default that works<br>
naively, and if the new eventspace is really useful, then do that with<br>
a non-default keyword.<br>
</blockquote>
<br></div>
Thanks for hashing all this out without me. :)<br>
<br>
Do we have a consensus? Is it this?<br>
<br>
 * Go back to default frame behavior (i.e. plot frames use main GUI<br>
   thread eventspace)<br>
<br>
 * Add #:new-thread? keyword argument (or a more suggestive name) to<br>
   `plot*&#39; functions that can return or display a frame<br>
<br>
 * Add `plot-new-thread?&#39; parameter for #:new-thread? default<br>
<br>
An alternative to the above is adding a `wait-for-plots&#39; procedure that syncs on all the plot frames&#39; eventspaces. But then this from Robby suggests separate eventspaces are dangerous in the first place:<div class="im">
<br>
<br>
&gt; if you were to invoke methods of the plot frame without first going<br>
&gt; to the new eventspace (via queue-callback or something like that), then<br>
&gt; you&#39;ll probably get bad behavior.<br>
<br></div>
I didn&#39;t know that.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div style>FWIW, I say &quot;probably&quot; here in the sense that I expect those methods manipulate internal state and that they aren&#39;t thread safe. You may have designed them to be, tho.</div>
<div style><br>Robby </div></div><br></div></div>