-
Notifications
You must be signed in to change notification settings - Fork 57
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
Race condition in FSNConnection #8
Comments
Thanks for the report; I haven't looked into it but this does sound like a real problem. Ideally failWithError would be idempotent but we have to be careful about the ref-counting semantics, because failWithError can cause the connection instance to be released. |
gwk
added a commit
to gwk/FSNetworking
that referenced
this issue
Jan 9, 2014
… checks if an error has been previously set, rather than triggering assertion.
gwk
added a commit
to gwk/FSNetworking
that referenced
this issue
Jan 9, 2014
… main thread; complete is idempotent by ignoring subsequent calls.
gwk
added a commit
to gwk/FSNetworking
that referenced
this issue
Jan 9, 2014
… main thread; complete is idempotent by ignoring subsequent calls.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
failWithError: is not designed to be called more than once, but in our case it is sometimes called twice: when the internet connectivity dies, and when UIApplication decides to run 'fireExpirationHandler'.
Presumably, 'endBackgroundTask' should prevent this from happening, but the first time failWithError: is called, 'complete' is enqueued on the run loop, and may be called only after the second call to failWithError:. Hence the race condition.
The text was updated successfully, but these errors were encountered: