Hackily fix thread safety issues in dynamic_lib#9713
Conversation
|
Similarly to #9194, I'm hesitant to include more half-baked implementations into I do think that statically initialized mutexes would be a useful thing to have, and this is certainly a good place where they'd be nice to have. That being said, this isn't the worst thing ever, so if there are indeed good reasons to get this patched over for now, I think that we could include it. |
|
Other code that needs a global lock does it by adding that lock along with _lock and _unlock functions to rust_builtin.cpp. I would rather do that than hand-roll spinlocks. |
|
Does that look better? |
src/libstd/unstable/dynamic_lib.rs
Outdated
There was a problem hiding this comment.
It seems a little odd to put these functions in the link_name = "dl" block because that's not the library that they come from. I'd be ok with scoping the dlerror_lock functions to just the relevant function that uses them as well.
|
Updated |
|
r+, thanks! |
|
I think this just needs an update of |
|
Should work now. |
|
Oops, one more try c.c |
The root issue is that dlerror isn't reentrant or even thread safe. The Windows code isn't affected since errno is thread-local on Windows and it's running in an atomically block to ensure there isn't a green thread context switch. Closes rust-lang#8156
The root issue is that dlerror isn't reentrant or even thread safe. The solution implemented here is to make a yielding spin lock over an AtomicFlag. This is pretty hacky, but the best we can do at this point. As far as I can tell, it isn't possible to create a global mutex without having to initialize it in a single threaded context. The Windows code isn't affected since errno is thread-local on Windows and it's running in an atomically block to ensure there isn't a green thread context switch. Closes #8156
4 participants
The root issue is that dlerror isn't reentrant or even thread safe.
The solution implemented here is to make a yielding spin lock over an
AtomicFlag. This is pretty hacky, but the best we can do at this point.
As far as I can tell, it isn't possible to create a global mutex without
having to initialize it in a single threaded context.
The Windows code isn't affected since errno is thread-local on Windows
and it's running in an atomically block to ensure there isn't a green
thread context switch.
Closes #8156