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.

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

Improve inline testing example #75

Merged
merged 2 commits into from
Jan 23, 2024

Conversation

adsteel
Copy link

@adsteel adsteel commented Jan 22, 2024

Problem

Previous example depended on the manager having been started via Run
or RunWithContext. This kicks off goroutines that result in data races
and flaky builds.

Solution

Make threadsafe manager setup method public. Update readme to explain how
to avoid requiring a call to mgr.Run* and the resulting data races.

@adsteel adsteel force-pushed the adsteel/improve-testing-suggestions branch 3 times, most recently from 1dd9cdc to 73570bd Compare January 22, 2024 15:20
@mperham
Copy link
Contributor

mperham commented Jan 22, 2024

This is not safe because syntheticPush is still not thread-safe. You're reassigning a new Pool to mgr for each call.

@adsteel
Copy link
Author

adsteel commented Jan 22, 2024

@mperham pool is only being reassigned if it is not already assigned. I may be missing something, but is that not thread safe?

@mperham
Copy link
Contributor

mperham commented Jan 22, 2024

Ah, right. That's far less bad but still unsafe. That pattern is called Check and Set. Another thread can execute between the Check and the Set.

@mperham
Copy link
Contributor

mperham commented Jan 22, 2024

I would move that pool management inside mgr so you can wrap it in a Mutex.

@adsteel adsteel force-pushed the adsteel/improve-testing-suggestions branch 2 times, most recently from 67ceaf6 to 25cf0fb Compare January 22, 2024 20:17
**Problem**

Previous example depended on the manager having been started via `Run`
or `RunWithContext`. This kicks off goroutines that result in data races
and flaky builds.

**Solution**

Make threadsafe manager setup method public. Update readme to explain how
to avoid requiring a call to `mgr.Run*` and the resulting data races.
@adsteel adsteel force-pushed the adsteel/improve-testing-suggestions branch from 25cf0fb to 7373583 Compare January 22, 2024 20:30
@adsteel
Copy link
Author

adsteel commented Jan 22, 2024

@mperham ah, that makes sense. I switched tack to reuse existing, thread safe logic that sets manager defaults, by exposing mgr.setUpWorkerProcess as public. Readme, commit and PR message are updated, and I just ran my test suite against this change and things look good so far.

@mperham
Copy link
Contributor

mperham commented Jan 22, 2024

If you’re adding public APIs, we’ll need a much stricter review.

@mperham
Copy link
Contributor

mperham commented Jan 22, 2024

I don't like this direction. You're asking the user to embed a lot of mgr setup, and therefore making it impossible to refactor that logic in future versions.

What about providing a mgr.InlineDispatch(job) method instead?

@adsteel
Copy link
Author

adsteel commented Jan 22, 2024

You're asking the user to embed a lot of mgr setup, and therefore making it impossible to refactor that logic in future versions.

Agreed, it's not ideal for maintenance.

What about providing a mgr.InlineDispatch(job) method instead?

That does feel more sustainable. It seems like it would be used exclusively for tests, yeah?

I just pushed up an implementation like that. What do you think of this direction?

@adsteel
Copy link
Author

adsteel commented Jan 22, 2024

This allows us to make the recently introduced mgr.Dispatch and mgr.IsRegistered private, for a net gain of one public method (that now needs tests).

@mperham mperham merged commit 80ee3f2 into contribsys:main Jan 23, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants