rx_didUpdateLocations crash on background thread. about rxswift

[kzaher]

Hi @GuyKahlon

I from the documentation that I've found online, it looks like CLLocationManager isn't thread safe class, and should be only manipulated from some thread that has runloop :) I don't think it's a usual pattern for users to create their own run loop, although, it's possible ofc.

I can't see any benefit of running CLLocationManager on your runloop instead of main thread, but I could be wrong about this.

I haven't found anything in official documentation that explicitly says the class is thread safe, which means it's not. I could be wrong about this, so if I've missed something, please let me know.

https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManager_Class/index.html#//apple_ref/occ/cl/CLLocationManager

First search results from Google also say it's a really good idea to work with CLLocationManager from main thread

https://www.google.hr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=off&q=cllocationmanager+thread+safe

http://www.touch-code-magazine.com/cllocationmanager-and-thread-safety/

http://stackoverflow.com/questions/4000537/receiving-cllocation-updates-on-a-background-thread

Were are you accessing shared instance of location manager, or did you create your own runloop and location manager?

[kzaher]

We've changed wording on error message, so it should be more helpful now.

if !NSThread.currentThread().isMainThread {
            rxFatalError("Executing on scheduler that is not main. Please use `MainScheduler.sharedInstance`.")
        }

I still think it's a good idea to leave this check :)

[AquaGeek]

FWIW: in watchOS 2 your extension won't necessarily get instantiated on the main thread (as it is instantiated via XPC), so ensuring objects get created on the main thread becomes problematic. The workaround I've used for now is to defer creation of the object that holds the location manager until applicationDidFinishLaunching().

[sergdort]

Hi, guys I wonder will subscribeOn operator help?

[AquaGeek]

@sergdort Unfortunately that doesn't help mitigate the issue.

[kzaher]

Hi @AquaGeek ,

yeah, I would suggest using it from main thread only because it's far easier to reason about what is happening. I doubt there would be any performance issues.

I've tried analyzing what would be necessary to make this thread safe, but it wasn't as trivial as it initially seemed since any possible mutations or reading should involve additional synchronization. That would add significant amount of additional synchronizations and make the code harder to read and reason about.

Then we would probably need to add multiple delegate proxy types (or a boolean parameter), one that allows being used from main thread, and other one that doesn't because we would need to safeguard accessing UI elements, so it just gets more and more complex.

I think people are having hard time understanding what is happening even now :)

We've decided for simpler, safer and hoping reasonable solution for now, unless we find some really compelling reasons to add that additional complexity.

¯_(ツ)_/¯