-
Notifications
You must be signed in to change notification settings - Fork 43
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
Improve inline testing example #75
Conversation
1dd9cdc
to
73570bd
Compare
This is not safe because syntheticPush is still not thread-safe. You're reassigning a new Pool to mgr for each call. |
@mperham pool is only being reassigned if it is not already assigned. I may be missing something, but is that not thread safe? |
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. |
I would move that pool management inside mgr so you can wrap it in a Mutex. |
67ceaf6
to
25cf0fb
Compare
**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.
25cf0fb
to
7373583
Compare
@mperham ah, that makes sense. I switched tack to reuse existing, thread safe logic that sets manager defaults, by exposing |
If you’re adding public APIs, we’ll need a much stricter review. |
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 |
Agreed, it's not ideal for maintenance.
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? |
This allows us to make the recently introduced |
Problem
Previous example depended on the manager having been started via
Run
or
RunWithContext
. This kicks off goroutines that result in data racesand 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.