This repository has been archived by the owner on Jul 31, 2023. It is now read-only.
Lazily initialize the view
package's default worker
#1287
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.
See discussion in #1191 for impetus, but in general, it's not
particularly good practice to start up goroutines in package
init
functions, with one reason being that it means that they're started for
projects that don't even make use of the package, and maybe just have it
as a transitive dependency.
So here, remove the
view
package's default worker in favor of a newfunction that'll lazily initialize one when any package-level functions
are called that use the default worker. We use a
sync.Once
that has anoptimized short-circuit path in case the work's already been done, so
new overhead should be negligible, and registering/unregistering views
is probably not a particularly common operation anyway.
This change is backwards compatible, with use of the package's API
staying exactly the same. Test coverage seems to be pretty good, with a
function that previously reset the default worker between test cases
which I've modified to instead reset the default worker back to its
uninitialized state, and thereby verify that the test cases can
initialize it if necessary.
I thought about trying to deinitialize the default worker in case its
last view is unregistered, but decided against it because (1) it's more
invasive, (2) it's not likely to actually help anyone in practice as
views probably stay registered for a program's entire duration anwyay,
and (3) its interaction with the existing package-level
Stop
functionwould take some thinking through.