Skip to content
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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Acceptance tests: prevent deadlocks in tests for async writes #27

Closed
wants to merge 2 commits into from
Closed

Acceptance tests: prevent deadlocks in tests for async writes #27

wants to merge 2 commits into from

Conversation

hariso
Copy link
Contributor

@hariso hariso commented Jun 8, 2022

Description

Fixes #26

Quick checks:

  • I have followed the Code Guidelines.
  • There is no other pull request for the same
    update/change.
  • I have written unit tests.
  • I have made sure that the PR is of reasonable size and can be easily reviewed.

@hariso hariso marked this pull request as ready for review June 8, 2022 11:54
@hariso hariso requested a review from a team as a code owner June 8, 2022 11:54
lovromazgon
lovromazgon reviewed Jun 8, 2022
View reviewed changes
acceptance_testing.go Outdated
@@ -1129,3 +1129,17 @@ func (a acceptanceTest) isEqualData(is *is.I, want, got Data) {
is.Equal(want.Bytes(), got.Bytes()) // data did not match (want != got)
}
}

func waitTimeout(wg *sync.WaitGroup, timeout time.Duration) bool {
Copy link
Member

Choose a reason for hiding this comment

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

I'm thinking if it would be worth it to add this function as a method to acceptanceTest and to ConfigurableAcceptanceTestDriver 🤔 it would mean it's duplicated, but on the other hand we prevent it from being used anywhere else and keep the package clean.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking about that too, but I didn't like the duplication at all. On the other hand, maybe it's not a bad thing at all that it's accessible to the rest of the package. I'd maybe move it to a utils package or import it from a library.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Lovro and I talked about this "offline". Similar functionality is needed in other places, so we'll extract this function into a separate file.

@hariso hariso requested a review from lovromazgon June 9, 2022 13:43
dylanlott
dylanlott reviewed Jun 9, 2022
View reviewed changes
Copy link

@dylanlott dylanlott left a comment

Choose a reason for hiding this comment

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

I saw the comment about pulling the wait utils functions into a separate file or package. I would be in favor of a separate package entirely over a file, especially if these functions are useful concurrency patterns for acceptance tests et. al. Looks good!

@lovromazgon
Copy link
Member

lovromazgon commented Jun 9, 2022 •
edited
Loading

Something was bugging me about these functions, bugging me to the point that I took the time to play around with a completely different approach. Here's what I came up with: a9290b4.

The idea is to have types that extend the functionality of sync.WaitGroup and chan with the functionality we need. Even if you use the original type you can cast it to our internal type and use the extended functionality, e.g.:

var wg sync.WaitGroup
err := (*internal.WaitGroup)(&wg).Wait(ctx)
// or
err := (*internal.WaitGroup)(&wg).WaitTimeout(ctx, time.Second)

c := make(chan struct{})
val, ok, err := internal.Chan[struct{}](c).Recv(ctx)
// or
val, ok, err := internal.Chan[struct{}](c).RecvTimeout(ctx, time.Second)

Or you can use the internal types directly (as I did in the commit). WDYT @hariso?

@hariso
Copy link
Contributor Author

hariso commented Jun 13, 2022

@lovromazgon Nice! I've seen a similar approach in a library I was considering (introducing a dependency for a thing as simple as this wasn't really appealing). Your approach with types is more elegant though! Since we're basically writing our own WaitGroup alternative, we'd need tests for the new as well as the existing WaitGroup functionality. If we can agree the the scope change is OK and pays out, I think it's be cool seeing this merged. 👍

@lovromazgon
Copy link
Member

Glad to hear you like the approach.

we'd need tests for the new as well as the existing WaitGroup functionality

I totally agree, I didn't include them since I made the commit more as an exploration to see if it made sense. Do you want me to write the tests or do you want to include the commit in your PR and write tests for it?

@hariso hariso marked this pull request as draft June 13, 2022 15:20
@hariso
Copy link
Contributor Author

hariso commented Jun 13, 2022

FTR, I'll include Lovro's commit into this PR and add tests. I'll convert this PR into a draft to finish another issue first.

@hariso
Copy link
Contributor Author

hariso commented Jul 6, 2022

We're punting on #26 for now, so I'll close this.

@hariso hariso closed this Jul 6, 2022
@hariso hariso deleted the haris/timeouts branch March 7, 2023 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dylanlott dylanlott dylanlott left review comments

@lovromazgon lovromazgon Awaiting requested review from lovromazgon

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Acceptance tests: prevent deadlocks in tests for async writes
3 participants
@hariso @lovromazgon @dylanlott