You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 21, 2023. It is now read-only.
If an application attempts to take a snapshot before ever initializing an MGLMapView or interacting with MGLOfflineStorage directly, -[MGLMapSnapshotter startWithQueue:overlayHandler:completionHandler:] raises an exception:
format:@"startWithQueue:completionHandler: must be called from a thread with an active run loop."];
}
This check is premature, since the method soon afterwards causes MGLOfflineStorage to create an mbgl::util::RunLoop and various file sources on the current thread:
If we were to simply remove or defer this check, the check would pass even if starting the snapshotter on a background thread. However, the static mbgl::util::RunLoop intended for the main thread would be created for a background thread, which would lead to undefined behavior, for example when subsequently using MGLMapView.
Before #210, the same application didn’t trigger the exception because -[MGLMapSnapshotter initWithOptions:] happened to call -setOptions:, which called +[MGLOfflineStorage sharedOfflineStorage] before the run loop check. Even so, if a developer happened to initialize the snapshotter on a background thread, the static RunLoop intended for the main thread would’ve been created on the background thread.
One potential fix would be to call +[MGLOfflineStorage sharedOfflineStorage] in +[MGLMapSnapshotter initialize], but that could potentially impact startup time even in applications that don’t use MGLMapSnapshotter earlly on. Another fix would be to replace the existing check with one that explicitly raises an exception if it’s on a background thread but calls +[MGLOfflineStorage sharedOfflineStorage] if it’s on the main thread.
Thanks to @julianrex for spotting and helping to diagnose this issue.
No, that was a workaround in an internal testing repository. (The workaround is to call +[MGLOfflineStorage sharedOfflineStorage] pro forma before creating a snapshotter.)
If an application attempts to take a snapshot before ever initializing an MGLMapView or interacting with MGLOfflineStorage directly,
-[MGLMapSnapshotter startWithQueue:overlayHandler:completionHandler:]
raises an exception:mapbox-gl-native-ios/platform/darwin/src/MGLMapSnapshotter.mm
Lines 267 to 270 in 81df48d
This check is premature, since the method soon afterwards causes MGLOfflineStorage to create an
mbgl::util::RunLoop
and various file sources on the current thread:mapbox-gl-native-ios/platform/darwin/src/MGLMapSnapshotter.mm
Line 285 in 81df48d
mapbox-gl-native-ios/platform/darwin/src/MGLMapSnapshotter.mm
Line 664 in 81df48d
mapbox-gl-native-ios/platform/darwin/src/MGLOfflineStorage.mm
Line 64 in 81df48d
mapbox-gl-native-ios/platform/darwin/src/MGLOfflineStorage.mm
Line 223 in 81df48d
mapbox-gl-native-ios/platform/darwin/src/MGLFoundation.mm
Line 5 in 81df48d
If we were to simply remove or defer this check, the check would pass even if starting the snapshotter on a background thread. However, the static
mbgl::util::RunLoop
intended for the main thread would be created for a background thread, which would lead to undefined behavior, for example when subsequently using MGLMapView.Before #210, the same application didn’t trigger the exception because
-[MGLMapSnapshotter initWithOptions:]
happened to call-setOptions:
, which called+[MGLOfflineStorage sharedOfflineStorage]
before the run loop check. Even so, if a developer happened to initialize the snapshotter on a background thread, the staticRunLoop
intended for the main thread would’ve been created on the background thread.One potential fix would be to call
+[MGLOfflineStorage sharedOfflineStorage]
in+[MGLMapSnapshotter initialize]
, but that could potentially impact startup time even in applications that don’t use MGLMapSnapshotter earlly on. Another fix would be to replace the existing check with one that explicitly raises an exception if it’s on a background thread but calls+[MGLOfflineStorage sharedOfflineStorage]
if it’s on the main thread.Thanks to @julianrex for spotting and helping to diagnose this issue.
/cc @mapbox/maps-ios @alexshalamov
The text was updated successfully, but these errors were encountered: