Replace drainUntilIdle with a dispatch_barrier_sync for Breakpad tests

Replace drainUntilIdle with a dispatch_barrier_sync for Breakpad tests

drainUntilIdle was a crutch because it didn't fully eliminate the race
condition between Breakpad setting its state on its own queue and the
tests.
This CL adds a test method to get the BreakpadController queue and
dispatches a barrier block on it to wait until the BreakpadController
updated its state.

Previously:
https://codereview.chromium.org/2760973002/
https://codereview.chromium.org/2775403003/

BUG=700839
R=baxley@chromium.org
CC=olivierrobin@chromium.or

Review-Url: https://codereview.chromium.org/2827313002
Cr-Commit-Position: refs/heads/master@{#466065}
Committed: https://chromium.googlesource.com/chromium/src/+/5895ccc48d4395a1b5359a6ca8ca9eb654d4cd3d

[lpromero, 2017-04-20 15:23:04]

The CQ bit was checked by lpromero@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-20 15:23:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-20 15:37:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-20 15:37:13]

Dry run: This issue passed the CQ dry run.

[baxley, 2017-04-20 16:37:43]

LGTM

https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
File ios/chrome/test/app/chrome_test_util.mm (right):

https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
ios/chrome/test/app/chrome_test_util.mm:34: - (dispatch_queue_t)queue;
Probably outside the scope of this CL... Do you have any thoughts on public APIs
we could use to achieve something similar? Or perhaps things we could make
public APIs?

[lpromero, 2017-04-20 17:51:01]

On 2017/04/20 16:37:43, baxley wrote:
> LGTM
> 
>
https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
> File ios/chrome/test/app/chrome_test_util.mm (right):
> 
>
https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
> ios/chrome/test/app/chrome_test_util.mm:34: - (dispatch_queue_t)queue;
> Probably outside the scope of this CL... Do you have any thoughts on public
APIs
> we could use to achieve something similar? Or perhaps things we could make
> public APIs?

Either BreakpadController vends its queue (bad), or it takes it as a dependency
injected on initialization (better). But then we need the creator of the
BreakpadController to also vend the queue!

[lpromero, 2017-04-20 17:51:17]

The CQ bit was checked by lpromero@chromium.org

[commit-bot: I haz the power, 2017-04-20 17:51:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-20 17:57:54]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1492710677523680, "parent_rev":
"699ff2a6613e4dbd2b9357f4845c687e7104f41c", "commit_rev":
"5895ccc48d4395a1b5359a6ca8ca9eb654d4cd3d"}

[commit-bot: I haz the power, 2017-04-20 17:58:09]

Description was changed from

==========
Replace drainUntilIdle with a dispatch_barrier_sync for Breakpad tests

drainUntilIdle was a crutch because it didn't fully eliminate the race
condition between Breakpad setting its state on its own queue and the
tests.
This CL adds a test method to get the BreakpadController queue and
dispatches a barrier block on it to wait until the BreakpadController
updated its state.

Previously:
https://codereview.chromium.org/2760973002/
https://codereview.chromium.org/2775403003/

BUG=700839
R=baxley@chromium.org
CC=olivierrobin@chromium.or
==========

to

==========
Replace drainUntilIdle with a dispatch_barrier_sync for Breakpad tests

drainUntilIdle was a crutch because it didn't fully eliminate the race
condition between Breakpad setting its state on its own queue and the
tests.
This CL adds a test method to get the BreakpadController queue and
dispatches a barrier block on it to wait until the BreakpadController
updated its state.

Previously:
https://codereview.chromium.org/2760973002/
https://codereview.chromium.org/2775403003/

BUG=700839
R=baxley@chromium.org
CC=olivierrobin@chromium.or

Review-Url: https://codereview.chromium.org/2827313002
Cr-Commit-Position: refs/heads/master@{#466065}
Committed:
https://chromium.googlesource.com/chromium/src/+/5895ccc48d4395a1b5359a6ca8ca...
==========

[commit-bot: I haz the power, 2017-04-20 17:58:11]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/5895ccc48d4395a1b5359a6ca8ca...

[baxley, 2017-04-20 18:01:57]

On 2017/04/20 17:51:01, lpromero wrote:
> On 2017/04/20 16:37:43, baxley wrote:
> > LGTM
> > 
> >
>
https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
> > File ios/chrome/test/app/chrome_test_util.mm (right):
> > 
> >
>
https://codereview.chromium.org/2827313002/diff/1/ios/chrome/test/app/chrome_...
> > ios/chrome/test/app/chrome_test_util.mm:34: - (dispatch_queue_t)queue;
> > Probably outside the scope of this CL... Do you have any thoughts on public
> APIs
> > we could use to achieve something similar? Or perhaps things we could make
> > public APIs?
> 
> Either BreakpadController vends its queue (bad), or it takes it as a
dependency
> injected on initialization (better). But then we need the creator of the
> BreakpadController to also vend the queue!

Yeah, I didn't mean exposing the queue (which is what I didn't like in the test
code :)). Just curious if there was something higher level, but since we've
already exposed breakpad privates I don't think we're introducing anything worse
than what's already there. :(

Thanks for the fix and explanation.