Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

Race Condition Between freezeOperations and checkAndRestoreFrozenOperations in MKNetworkEngine #451

Open
kglee79 opened this issue Mar 4, 2015 · 0 comments

Comments

@kglee79
Copy link

kglee79 commented Mar 4, 2015

If reachability changes quickly enough (which was occurring a bunch during unit testing, but less likely in real life situations), if checkAndRestoreFrozenOperations is called while freezeOperations is still running, ops can be stuck in a frozen state until the next reachability change. Below is an outline of what was happening when I was unit testing a piece of my app and also explains why I was randomly seeing that operations were not being completed once connectivity was restored...

  • Assume an operation has been created and is in the operation queue.
  • When reachability changes to NotReachable, the freezeOperation function is called by MKNetworkEngine.
  • The freezeOperation function will attempt to freeze all operations in the queue, currently there is only one operation in the queue.
  • Before freezeOperation actually freezes the op to the file system, reachability changes and checkAndRestoreFrozenOperations is called to restore the frozen operations.
  • checkAndRestoreFrozenOperations checks the file system for frozen operations to restore. Since freezeOperation hasn't written the op to the file system yet, checkAndRestoreFrozenOperations thinks there's nothing to unfreeze so completes without doing anything.
  • Now control returns back to freezeOperation and it writes the frozen operation to the file system. However, since checkAndRestoreFrozenOperations was already called, this operation will be stuck there until the next time reachability changes from unreachable to reachable.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant