-
Notifications
You must be signed in to change notification settings - Fork 29.7k
[Impeller] Make ContextVK hash values globally unique #171119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ContextVK had been using a thread-local counter to assign the value returned by GetHash. But CommandPoolRecyclerVK was using these values as keys in a process-wide global map. If two engine instances using different task runner threads both created a ContextVK, then the thread-local counter could cause both contexts to share the same hash. So when CommandPoolRecyclerVK::DestroyThreadLocalPools destroys the pools associated with the first context's hash, it will also incorrectly destroy the second context's pools. Fixes flutter#170141
gaaclarke
left a comment
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.
lgtm with one minor request.
| // You could make a context once per nanosecond for 584 years on one thread | ||
| // before this overflows. | ||
| return ++tls_context_count; | ||
| return ++context_count; |
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.
The google convention is to not use operators with atomic values.
| return ++context_count; | |
| return context_count.fetch_add(1); |
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.
done
ContextVK had been using a thread-local counter to assign the value returned by GetHash. But CommandPoolRecyclerVK was using these values as keys in a process-wide global map. If two engine instances using different task runner threads both created a ContextVK, then the thread-local counter could cause both contexts to share the same hash. So when CommandPoolRecyclerVK::DestroyThreadLocalPools destroys the pools associated with the first context's hash, it will also incorrectly destroy the second context's pools. Fixes flutter#170141
ContextVK had been using a thread-local counter to assign the value returned by GetHash. But CommandPoolRecyclerVK was using these values as keys in a process-wide global map. If two engine instances using different task runner threads both created a ContextVK, then the thread-local counter could cause both contexts to share the same hash. So when CommandPoolRecyclerVK::DestroyThreadLocalPools destroys the pools associated with the first context's hash, it will also incorrectly destroy the second context's pools. Fixes flutter#170141
ContextVK had been using a thread-local counter to assign the value returned by GetHash. But CommandPoolRecyclerVK was using these values as keys in a process-wide global map.
If two engine instances using different task runner threads both created a ContextVK, then the thread-local counter could cause both contexts to share the same hash. So when CommandPoolRecyclerVK::DestroyThreadLocalPools destroys the pools associated with the first context's hash, it will also incorrectly destroy the second context's pools.
Fixes #170141