Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

chore(scaletest): add barrier synchronization primitive#19903

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
ethanndickson wants to merge1 commit intomainfromethan/scaletest-barrier

Conversation

ethanndickson
Copy link
Member

@ethanndicksonethanndickson commentedSep 22, 2025
edited
Loading

Relates tocoder/internal#889.

To fairly compare the latency of Coder Connect workspace updates, we require that all clients be listening for workspace updates before we begin creating workspaces, and thus workspace updates.

To support this, this PR adds a barrier synchronization primitive. Only onceWait orCancel has been calledsize times will a goroutine callingWait be unblocked.

TheCancel function exists to handle the case where an instance of a Coder Connect runner exits early, if user creation fails. This single failure should not cause all the other goroutines to block indefinitely.

@ethanndicksonGraphite App
Copy link
MemberAuthor

ethanndickson commentedSep 22, 2025
edited
Loading

This stack of pull requests is managed byGraphite. Learn more aboutstacking.

if b.count.Add(-1) == 0 {
close(b.done)
}
<-b.done
Copy link
MemberAuthor

@ethanndicksonethanndicksonSep 22, 2025
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I contemplated having API consumers pass a ctx intoWait, and then selecting on that to support individualWait timeouts.

I opted against this on the basis that:

  • I already needed to add theCancel function, to handle user creation failure.
  • Other goroutines can just call thatCancel function in a defer, such as when their own timeouts fire.

The outcome being that this line won't block forever if the API is used properly.

@ethanndicksonethanndicksonforce-pushed theethan/scaletest-barrier branch 2 times, most recently from297b92f toc906248CompareSeptember 22, 2025 09:17
@ethanndicksonethanndickson marked this pull request as ready for reviewSeptember 22, 2025 09:28
@spikecurtisGraphite App
Copy link
Contributor

Isn't this just aWaitGroup?

Like:

b := NewBarrier(5)

is

wg = new(sync.WaitGroup)wg.Add(5)

And

b.Wait()

is

wg.Done()wg.Wait()

I realize it's sometimes 2 calls instead of one, butWaitGroup is going to be familiar whereasBarrier will be a new thing that people have to learn.

Copy link
Contributor

@spikecurtisspikecurtis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think we actually need this. c.f. above comment

case <-done:
return
case <-ctx.Done():
t.Fatal("barrier should have released after cancel")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

we havetestutil.RequireReceive() for this since it comes up all the time.

@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsSep 25, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@spikecurtisspikecurtisspikecurtis left review comments

Assignees

@ethanndicksonethanndickson

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@ethanndickson@spikecurtis

[8]ページ先頭

©2009-2025 Movatter.jp