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'd rather it failed outright then pretend to succeed when it really hasn'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"><<a href="mailto:dimich@chromium.org">dimich@chromium.org</a>></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'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'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"><<a href="mailto:pedzsan@gmail.com" target="_blank">pedzsan@gmail.com</a>></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>
> The question is whether you queue or give an error.  When hitting the<br>
> RFC-ish per-host connection limits, browsers queue additional requests<br>
> from <img> or such, rather than erroring them out.  Not sure that's<br>
> the right model here, but I worry about how much boilerplate code<br>
> there will need to be to retry the connection (asynchronously) to<br>
> handle failures, and whether people will end up writing it or just<br>
> 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't see driving the retry via a scripting language to be bad.  Its not that hard and it won'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>