Protect access to renderables with a mutex#183813
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
There was a problem hiding this comment.
Code Review
This pull request introduces a mutex to protect concurrent access to the renderables_by_view_id hash table, which is shared between engine threads and the GTK thread. A GMutex is added to the FlEngine struct, and its lifecycle is correctly managed with initialization in fl_engine_init and cleanup in fl_engine_dispose. The core of the change is the introduction of three static helper functions (set_renderable, get_renderable, remove_renderable) that encapsulate thread-safe operations on the hash table using g_autoptr(GMutexLocker) for robust, exception-safe locking. All previous direct accesses to renderables_by_view_id have been refactored to use these new helpers, effectively resolving the potential race condition.
Renderables are stored in a hash table. This is accessed by engine threads and GTK so should be protected with a mutex.
Renderables are stored in a hash table. This is accessed by engine threads and GTK so should be protected with a mutex.
Renderables are stored in a hash table. This is accessed by engine threads and GTK so should be protected with a mutex.