I think that queuing in chrome bends the intent of the createWorker api just a little too far and will be happy to see it go away. I&#39;d rather it failed outright then pretend to succeed when it really hasn&#39;t.<div><br>
</div><div>(Actually that queuing code complicates the impl somewhat too... can you tell its been annoying me recently ;)<br><br><div class="gmail_quote">On Thu, May 13, 2010 at 5:36 PM, Dmitry Titov <span dir="ltr">&lt;<a href="mailto:dimich@chromium.org">dimich@chromium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As an example from a bit different area, in Chrome the Web Workers today require a separate process per worker. It&#39;s not good to create too many processes so there is a relatively low limit per origin and higher total limit. Two limits help avoid situation when 1 bad page affects others. Once limit is reached, the worker objects are created but queued, on a theory that pages of the same origin could cooperate, while if a total limit is blown then hopefully it&#39;s a temporary condition. Not ideal but if there should be a limit we thought having 2 limits (origin/total) is better then have only a total one.</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><div>
<br><br><div class="gmail_quote">On Thu, May 13, 2010 at 4:55 PM, Perry Smith <span dir="ltr">&lt;<a href="mailto:pedzsan@gmail.com" target="_blank">pedzsan@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><br>
On May 13, 2010, at 12:40 PM, Mike Shaver wrote:<br>
<br>
&gt; The question is whether you queue or give an error.  When hitting the<br>
&gt; RFC-ish per-host connection limits, browsers queue additional requests<br>
&gt; from &lt;img&gt; or such, rather than erroring them out.  Not sure that&#39;s<br>
&gt; the right model here, but I worry about how much boilerplate code<br>
&gt; there will need to be to retry the connection (asynchronously) to<br>
&gt; handle failures, and whether people will end up writing it or just<br>
&gt; hoping for the best.<br>
<br>
</div>Ah.  Thats a good question.  (Maybe that was the original question.)<br>
<br>
Since web sockets is the topic and as far as I know web sockets are only used by javascript, I would prefer an error over queuing them up.<br>
<br>
I think javascript and browser facilities have what is needed to create its own retry mechanism if that is what a particular situation wants.  I don&#39;t see driving the retry via a scripting language to be bad.  Its not that hard and it won&#39;t happen that often.  And it gives the javascript authors more control and choices.<br>


<br>
Thats my vote...<br>
<br>
pedz<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>