-
Notifications
You must be signed in to change notification settings - Fork 41
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
Bug: Tomb Wait
blocks forever when no Goroutine is ever spawned.
#21
Comments
That's by design. It prevents the potential race between Wait and Go. The proper way to use a tomb is to never hand it off for someone to Wait on it unless you do intend to use it. |
Appreciate the fast reply. Obviously there was another issue opened with the same subject. Sorry about create a duplicate. |
mardy
added a commit
to mardy/snapd
that referenced
this issue
Dec 6, 2021
Do not initialize the loopTomb member until we are actually asking it to run some routine. Otherwise the call to loopTomb.Wait() which we do when stopping the Overlord could block forever. This seems also to be the suggestion given in go-tomb/tomb#21 to a similar problem.
mardy
added a commit
to mardy/snapd
that referenced
this issue
Dec 6, 2021
Do not initialize the loopTomb member until we are actually asking it to run some routine. Otherwise the call to loopTomb.Wait() which we do when stopping the Overlord could block forever. This seems also to be the suggestion given in go-tomb/tomb#21 to a similar problem.
mardy
added a commit
to mardy/snapd
that referenced
this issue
Dec 6, 2021
Do not initialize the loopTomb member until we are actually asking it to run some routine. Otherwise the call to loopTomb.Wait() which we do when stopping the Overlord could block forever. This seems also to be the suggestion given in go-tomb/tomb#21 to a similar problem.
mardy
added a commit
to mardy/snapd
that referenced
this issue
Dec 13, 2021
Do not initialize the loopTomb member until we are actually asking it to run some routine. Otherwise the call to loopTomb.Wait() which we do when stopping the Overlord could block forever. This seems also to be the suggestion given in go-tomb/tomb#21 to a similar problem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you call
tmb.Wait()
on a tomb that has never calledtmb.Go
, it blocks forever.Here's a failing test case to reproduce the bug:
Here's the output of the test case using tomb d5d1b58:
The text was updated successfully, but these errors were encountered: