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

Add AudioFile cancellation #13

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

benpye
Copy link
Contributor

@benpye benpye commented Nov 20, 2018

This allows an AudioFile to be cancelled. This is useful to avoid network traffic and memory consumption when you wish to switch tracks before the first has finished.

@anisse
Copy link
Contributor

anisse commented Jan 27, 2019

Running a client through the race detector with this patch I found that this creates a data race on Cancel(). The simple fix is to just protect the cancelled variable with a (RW)Mutex, but the more idiomatic way is probably to use context and cancellation.

@benpye
Copy link
Contributor Author

benpye commented Feb 14, 2019

@anisse I don't really understand what the race condition would be, can you elaborate?

@anisse
Copy link
Contributor

anisse commented Feb 14, 2019

I wish I had saved the race detector output (will try to reproduce), but the gist is, from memory:

  • AudioFile fetching happens in a goroutine
  • that goroutine regularly reads the cancelled variable to know when to stop
  • you call Cancel () from another goroutine, so there's a datarace when writing the cancelled variable while the other goroutine might read it.

I fixed it like this in my fork : anisse/librespot-golang@23aeb87 and the parent commit : anisse/librespot-golang@62ca6aa

Reflecting again, atomics could have been used instead of a mutex.

@benpye
Copy link
Contributor Author

benpye commented Feb 15, 2019

I can see the chance for a read-whilst-write, but I'm not sure that it's problematic anyway, unless Golang forces that to be an error? If we incorrectly read that it's not-cancelled then it will be cancelled the next time we check, very shortly after, we cannot incorrectly read that it is cancelled as far as I can tell.

Have I missed something?

@anisse
Copy link
Contributor

anisse commented Feb 15, 2019

Golang doesn't force that to be an error per se, but your CPU might serve you incoherent data. The Go doc specifies that concurrent write and read access must be serialized. See: https://golang.org/ref/mem

Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access

And the guide to the data races : https://golang.org/doc/articles/race_detector.html

@xplodwild
Copy link
Contributor

@anisse Could you make a PR with your patch so I can integrate it here for everyone? Thanks

@anisse
Copy link
Contributor

anisse commented Feb 26, 2019

@xplodwild : done with #16 , but I didn't include the fix to @benpye 's cancellation since it hasn't been merged yet.

@xplodwild
Copy link
Contributor

@anisse Thanks, I had notifications off for the repo so I missed a bunch of things, but will review them throughout the day and get up to speed.

@benpye
Copy link
Contributor Author

benpye commented Feb 26, 2019

Hey @xplodwild @anisse , I'll try and update this PR tonight to fix the data race.

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.

3 participants