[Mac] Make CocoaTest::TearDown() more scalable in the face of valgrind.

[Mac] Make CocoaTest::TearDown() more scalable in the face of valgrind.

Changes from std::vector<> to std::set<> because set_difference()
works on sorted inputs.

The loop is broken into two parts.  The outer loop continues
while progress is being made.  The inner loop spins the event
loop while:
 - no progress has been made; and
   - it hasn't spun enough times; or
   - it hasn't spun for long enough

The odd timeout calculation is because some sequences need the
event loop spun after a timeout, not until a timeout (difference
between taking the time at the start and at the end).

As long as I was changing comments, I (hopefully) removed the
royal "We" in appeasement of The Mentovai.

BUG=36677
TEST=tests continue to work, even under valgrind

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

[Scott Hess - ex-Googler, 2010-02-26 23:04:04]

This CL provoked by complaints about not being able to enable some tests on the
valgrind bots, and a (probably related) failure Rohit had earlier in the week.

[Mark Mentovai, 2010-02-27 00:16:13]

LG

http://codereview.chromium.org/660213/diff/1/2
File chrome/browser/cocoa/cocoa_test_helper.h (right):

http://codereview.chromium.org/660213/diff/1/2#newcode85
chrome/browser/cocoa/cocoa_test_helper.h:85: // contents aren't retained, so you
can only use the pointer values
And you think "you" is any better?  :P

http://codereview.chromium.org/660213/diff/1/3
File chrome/browser/cocoa/cocoa_test_helper.mm (right):

http://codereview.chromium.org/660213/diff/1/3#newcode118
chrome/browser/cocoa/cocoa_test_helper.mm:118: // Check the timeout before
pumping events, so that we'll spin
Appeasement?

http://codereview.chromium.org/660213/diff/1/3#newcode120
chrome/browser/cocoa/cocoa_test_helper.mm:120: one_more_time = ([start_date
timeIntervalSinceNow] > -kCloseTimeout);
I guess this spins pretty heavily when the event queue is empty, then?

[Scott Hess - ex-Googler, 2010-02-27 00:37:27]

http://codereview.chromium.org/660213/diff/1/2
File chrome/browser/cocoa/cocoa_test_helper.h (right):

http://codereview.chromium.org/660213/diff/1/2#newcode85
chrome/browser/cocoa/cocoa_test_helper.h:85: // contents aren't retained, so you
can only use the pointer values
On 2010/02/27 00:16:13, Mark Mentovai wrote:
> And you think "you" is any better?  :P

Fixed.

http://codereview.chromium.org/660213/diff/1/3
File chrome/browser/cocoa/cocoa_test_helper.mm (right):

http://codereview.chromium.org/660213/diff/1/3#newcode120
chrome/browser/cocoa/cocoa_test_helper.mm:120: one_more_time = ([start_date
timeIntervalSinceNow] > -kCloseTimeout);
On 2010/02/27 00:16:13, Mark Mentovai wrote:
> I guess this spins pretty heavily when the event queue is empty, then?

Yeah.  I was a little nervous about tweaking this aspect of things.  AFAICT from
experimentation, sometimes an afterDelay schedules an afterDelay, with short or
zero delays, so in that case you really do want to spin as fast as possible. 
Other times nothing happens until a modest time has passed, then once things
start happening the loop needs to spin a few more times.

One "solution" would be to intercept afterDelay, and when we get to TearDown()
force any remaining items through in the order implied by the delays, but
without the actual delay.  Getting the reentrancy and autorelease stuff right
would probably be challenging, but there you go.  Probably not worthwhile unless
we find another hole.