Disable RSpec thread safety switch
What does this MR do and why?
This is known to cause issues with Ruby 3, which changed lock semantics to be per-fiber: https://github.com/rspec/rspec-core/issues/2064#issuecomment-1299974845
When testing code that uses co-routines, then
even in the absence of multiple threads this
can lead to deadlocks. The threadsafe
switch was originally added to support Ruby VMs that do not use a GIL (JRuby, Rubinus etc): https://github.com/rspec/rspec-core/pull/1858
We use MRI, so this does not affect us.
I am also not aware of any reasons why we would want to utilize multiple threads in test code, so we should set this to false to prevent RSpec from creating mutexes around memoized blocks (subject, let). If we need to do that in a minority of tests, the developer can still use a lock to protect access to shared memory.
Note as well that the current thinking is to deprecate -- I misread this; the intention is to remove just the option and default it to true instead.threadsafe
with RSpec 4: https://github.com/rspec/rspec-core/issues/2064#issuecomment-272715067
A nice side-effect of this could be improved performance since we can forgo the necessity to synchronize on a Mutex
for every call to subject
and let
: https://github.com/rspec/rspec-core/blob/6dede8ae1b9cce6e1de4baa912e77c97b587b446/benchmarks/threadsafe_let_block.rb#L216
Links:
- https://github.com/rspec/rspec-core/issues/2064
- !102625 (closed)
- https://app.periscopedata.com/app/gitlab/652085/EP---Jobs-Durations
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #379686 (closed)