#[inject] is not thread-safe

[kennytm]

Repro step:

1. Make sure your CPU has ≥2 cores.
2. cargo test --test test
3. The test will fail most of the time.

The problem is that test_with_silly_func_1 and test_with_silly_func_2 will both modify the same _mock_me_test_context_instance. Now imagine the following sequence:

Thread 1	Thread 2
_mock_me_test_context_instance.set(replacement_1)
	_mock_me_test_context_instance.set(replacement_2)
function_with_fun_id()
_mock_me_test_context_instance.get()
Finds out silly_func becomes replacement_2
Computes replacement_2(30, 20)
assert_eq!(600, 10)
💥

---

Tested with mock_me = "0.2.2" on crates.io.

$ rustc -vV
rustc 1.21.0-nightly (e26688824 2017-08-27)
binary: rustc
commit-hash: e2668882406b68739c6ed33d420358d5d710e67b
commit-date: 2017-08-27
host: x86_64-apple-darwin
release: 1.21.0-nightly
LLVM version: 4.0

[craftytrickster]

Thank you for reporting this. I am able to reproduce this error after running the command a bunch of times. Hopefully there is a way to protect this from occurring, I will look to see if there is a solution.

[craftytrickster]

Unfortunately, there seems to be no easy way around this issue. As a result, I have removed one of the conflicting tests from the file, to avoid the random crashes. However, this seems to be indicative a fatal limitation in this crate.

[SupernaviX]

Could you key _mock_me_test_context_instance.get off the name/namespace of the test itself, as well as the function being mocked?

[craftytrickster]

Unfortunately, the mock and inject steps are completely independent of each other and I cannot find a way share namespace type information between them when defining the context key. One way to maybe get around it is to make them define as many keys up front as they would like to mock, such as fun1|fun2="...". At that point, it becomes pretty unergonomic unfortunately, I am not sure if it is even worth pursuing.