Fix some race conditions in concurrent initialization #3611
Conversation
When concurrently calling filter_registry_initialize, it's possible for two threads to try to initialize the global `git__filter_registry` variable. One thread will fail the CAS, returning the current value of `git__filter_registry`, but it will then unfortunately *free* that current value. Instead store the found global registry in another local variable and free just our own local copy.
If this function was concurrently called, it was possible for all threads entering to call `git__on_shutdown` which could possibly trigger the assert that there aren't too many shutdown handlers (as each thread entering would try to register one). This adds an atomic variable to count the number of threads entering, and only the first will register a shutdown handler. Additionally, the shutdown handler no longer flags itself as not having been set, as it is indeed still set.
f95445d to
1f5d3e9
Compare
|
What do you mean exactly by "concurrent initialization"... Are you running |
|
Ah sorry, by concurrent initialization I meant on behalf of the threads calling these functions, for example if two threads call |
|
The filter initialisation looks correct, though @ethomson has done a larger refactor around them in #3597. It does look like we would need better synchronization around |
|
Ok, sounds like some more invasive changes are probably needed here, so closing. |
Some of the travis tests I have for the git2-rs Rust library for libgit2 have been failing a lot recently with the error:
Curious as to why this was happening, I scrutinized some of the calls to
git__on_shutdown, and I think the latter of these two commits may be the cause of this. Unfortunately I wasn't ever able to reproduce locally, so I'm not sure that this fixes the bug I'm seeing, but it seems like these may want to be fixed regardless!