Changed CreateWorker to coalesce any matching queued shared workers when a

Changed CreateWorker to coalesce any matching queued shared workers when a
shared worker is started.

Added tests for worker close and queued shared worker cases.
BUG=29998
TEST=new UI tests added.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=38549

[jam, 2010-02-08 00:08:28]

http://codereview.chromium.org/580007/diff/1001/1011
File chrome/worker/worker_uitest.cc (right):

http://codereview.chromium.org/580007/diff/1001/1011#newcode512
chrome/worker/worker_uitest.cc:512: // to allow the queued worker to be
executed.
I'm a little confused from this statement and the bug description below:

1. Create > 16 shared workers in a single tab. 17th will be queued.
2. Have another tab create the shared worker that was queued in #1
3. Close a worker in the first tab, so the queued worker gets started.

Why should the second tab's shared workers get queued up?  It seems that the
other tab hitting the 16 worker process limit shouldn't affect this tab, just
like it wouldn't for dedicated workers.  In which case, its two shared workers
should start up right away without waiting for the first tab to kill a worker. 
Am I missing something?

[Andrew T Wilson (Slow), 2010-02-09 05:09:22]

Turns out after I thought about it some more that I was not handling another
case (multiple queued instances corresponding to the same shared worker). I've
added code to deal with this and added another couple of tests to verify that
behavior. Thanks for pointing out the comment discrepancy as I wouldn't have
caught this otherwise.

http://codereview.chromium.org/580007/diff/1001/1011
File chrome/worker/worker_uitest.cc (right):

http://codereview.chromium.org/580007/diff/1001/1011#newcode512
chrome/worker/worker_uitest.cc:512: // to allow the queued worker to be
executed.
On 2010/02/08 00:08:28, John Abd-El-Malek wrote:
> I'm a little confused from this statement and the bug description below:
> 
> 1. Create > 16 shared workers in a single tab. 17th will be queued.
> 2. Have another tab create the shared worker that was queued in #1
> 3. Close a worker in the first tab, so the queued worker gets started.
> 
> Why should the second tab's shared workers get queued up?  It seems that the
> other tab hitting the 16 worker process limit shouldn't affect this tab, just
> like it wouldn't for dedicated workers.  In which case, its two shared workers
> should start up right away without waiting for the first tab to kill a worker.

> Am I missing something?

Sorry, the comment describes the old buggy behavior (where starting the worker
in the new tab would not launch the worker queued from the first tab, but a
duplicate copy of that worker would indeed get launched when a worker was shut
down). 

So now that I've fixed the bug, this test case could be even simpler (no need to
shutdown any workers at all). I've made this change.

[jam, 2010-02-09 22:47:51]

lgtm