Lock-free LocationManager instantiation #352
Conversation
| // since the access to locationManager might happen in | ||
| // main thread after this function call but before | ||
| // mainQueue async. | ||
| dispatch_sync(dispatch_get_main_queue(), ^{ |
There was a problem hiding this comment.
theoretically this can deadlock as well. If you sync on background thread from the main one while background thread will call this method.
Not sure if it is possible scenario with this lib though.
There was a problem hiding this comment.
hm, you are right. Any ideas on how to fix that? 🙂
There was a problem hiding this comment.
this approach seem to work, take a look
Deadlock.zip
There was a problem hiding this comment.
just not sure about run loop. it is not guaranteed to be available.
There was a problem hiding this comment.
I think it is acceptable risk. My point is that sync call from main thread to the background queue in not something common and should be generally avoided as a bad practice leading to the UI lags.
There was a problem hiding this comment.
Thanks for providing a workaround. It seems to have some overhead so I will avoid it at the moment. In case of any issues reports I will reconsider my position.
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: