Fix race conditions when creating watches#1113
Fix race conditions when creating watches#1113knative-prow-robot merged 9 commits intoknative:masterfrom
Conversation
…on that emits the event it is watching for
knative-prow-robot
left a comment
There was a problem hiding this comment.
@akerekes: 2 warnings.
Details
In response to this:
Description
Fix a race condition between creating a watch and initiating the action that emits the event it is watching for.
Currently the wait.Wait function creates the watch and is invoked in a goroutine, i.e. parallel to the command whose result the watch is targeted for. If the watch creation takes longer in the goroutine than the main execution thread's call to the backend, the event generated by the change can be emitted sooner than the watch is listening and it will wait there until timeout happens.
Changes
- Update
wait.Wait.Wait()to accept a watch, instead of the implementing types creating it- Update callers of
wait.Wait.Wait()to create the watch upfrontReference
Fixes #1109
/lint
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
|
The following is the coverage report on the affected files.
|
|
Thanks ! looking at it tomorrow ... |
rhuss
left a comment
There was a problem hiding this comment.
Good catch ! Looks good to me (one minor question though), and sorry for the delay in reviewing this.
/approve
/lgtm
| waitForEvent := wait.NewWaitForEvent("service", cl.WatchService, func(evt *watch.Event) bool { return evt.Type == watch.Deleted }) | ||
| err, _ := waitForEvent.Wait(serviceName, wait.Options{Timeout: &timeout}, wait.NoopMessageCallback()) | ||
| waitForEvent := wait.NewWaitForEvent("service", func(evt *watch.Event) bool { return evt.Type == watch.Deleted }) | ||
| err, _ := waitForEvent.Wait(watcher, serviceName, wait.Options{Timeout: &timeout}, wait.NoopMessageCallback()) |
There was a problem hiding this comment.
This closure works as long as watcher is in scope. Not sure how it works in go, but if this variable would go out of scope (e.g. when this function where it is allocated is left), wouldn't it be garbage collected and the go routine (in case it is still running) would then access a zombie watcher object ?
I know in this case this is a theoretical question, as we block on the channel before leaving the function, and only the goroutine can send to the channel.
So it's more a theoretical question, I guess :)
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akerekes, navidshaikh, rhuss The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* Fix a race condition between creating a watch and initiating the action that emits the event it is watching for * update changelog * add PR ID to changelog entry * Fix merge in Changelog * Fix table format in Changelog
* Fix a race condition between creating a watch and initiating the action that emits the event it is watching for * update changelog * add PR ID to changelog entry * Fix merge in Changelog * Fix table format in Changelog
* Embed the namespace in request body while creating channels (#1117) * Embed the namespace in request body while creating channels since on the eventing side, defaulting for channel isnt picking the namespace from the context (see knative/eventing#4514) workaround for #1100 this changeset should be reverted when eventing#4514 is resolved * Add CHANGELOG * Update CHANGELOG for v0.19.1 * Cross-compile the kn binary for linux/s390x (#1083) * Update CHANGELOG for v0.19.1 * Fix date in changelog * Fix race conditions when creating watches (#1113) * Fix a race condition between creating a watch and initiating the action that emits the event it is watching for * update changelog * add PR ID to changelog entry * Fix merge in Changelog * Fix table format in Changelog
* Cross-compile the kn binary for linux/s390x (#1083) * Update CHANGELOG for kn v0.18.4 * Fix race conditions when creating watches (#1113) * Fix a race condition between creating a watch and initiating the action that emits the event it is watching for * update changelog * add PR ID to changelog entry * Fix merge in Changelog * Fix table format in Changelog
This reverts commit 83b8635.
Description
Fix a race condition between creating a watch and initiating the action that emits the event it is watching for.
Currently the wait.Wait function creates the watch and is invoked in a goroutine, i.e. parallel to the command whose result the watch is targeted for. If the watch creation takes longer in the goroutine than the main execution thread's call to the backend, the event generated by the change can be emitted sooner than the watch is listening and it will wait there until timeout happens.
Changes
wait.Wait.Wait()to accept a watch, instead of the implementing types creating itwait.Wait.Wait()to create the watch upfrontReference
Fixes #1109
/lint