-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[core] annotation manager thread safety #9208
Conversation
23eef39
to
10e09da
Compare
10e09da
to
62ed108
Compare
AnnotationManager::~AnnotationManager() = default; | ||
|
||
AnnotationID AnnotationManager::addAnnotation(const Annotation& annotation, const uint8_t maxZoom) { | ||
AnnotationID AnnotationManager::addAnnotation(const Annotation &annotation, const uint8_t maxZoom) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you revert the &
whitespace changes?
I'm not sure that this is going to be a viable approach. The SDKs already expose non-bulk APIs, right? If those APIs change their performance in a major way, such that existing workloads become much slower, and the only way to recover performance is to switch to bulk APIs, then I would consider that a breaking change. I think in order for the immutable approach to be viable, copies must be fairly cheap. So, either:
The second is possible in this case, but would need a sizable investment in immutable datastructures -- we'd need an immutable rtree implementation, for one. This approach also feels to me like it takes us further away from where we want Since |
Ok. Continuing in #9220 |
Cuts up the annotation manager so is thread safe (#8820);
TODO:
SourceObserver::onSourceChanged
callbacks. When mutating theAnnotationSource
rapidly, this is quite the bottleneck. Since these callbacks are needed to signal changes for style diffing, we need to make sure any other operations either use a different signal or guard better from redundantly executing.Fixes: