This PR address the deadlock issue.
Sometimes access to MMELocationManager/locationManager happens in the middle of the original locationManager getter. For example, code with access to locationManager can be scheduled for the next main RunLoop run, and then the getter would schedule its own internal initialization to the main queue and keep holding the @synchronized lock. And on the next RunLoop run when an arbitrary access code would be called that lock would stop the main queue execution without a way to break the deadlock.
Some extra context in the internal discussion.
This PR address the deadlock issue. Sometimes access to
MMELocationManager/locationManagerhappens in the middle of the originallocationManagergetter. For example, code with access tolocationManagercan be scheduled for the next main RunLoop run, and then the getter would schedule its own internal initialization to the main queue and keep holding the@synchronizedlock. And on the next RunLoop run when an arbitrary access code would be called that lock would stop the main queue execution without a way to break the deadlock. Some extra context in the internal discussion.Fixes https://mapbox.atlassian.net/browse/CORESDK-1440
Related: