transport tests: refactor workers in TestMoreStreamsThanOurLimits #2472
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this test is to make a bunch of requests in parallel and hit a peer's limits and eventually make all our requests. The test starts with a certain number of workers and increases them exponentially as long as we haven't seen an error.
The previous code did this as well, but it was extremely subtle. I think this refactor is much clearer in its intent. Instead of having a semaphore that controls the number of workers allowed to run at once, we have dedicated worker goroutines that pull work from a queue. The initial worker (index=0) is special in that it can spawn more workers. This makes it clear who is increasing the worker count and how many parallel workers we have.
This also allows us to set initial worker counts and max worker counts easily, which is useful for debugging some transports.
The core logic of each worker hasn't changed, so it may be useful to review with
?w=1
github flag to ignore whitespace changes.