Skip to content

Disable RSpec thread safety switch

Matthias Käppler requested to merge 379686-drop-rspec-threadsafe into master

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 threadsafe with RSpec 4: https://github.com/rspec/rspec-core/issues/2064#issuecomment-272715067 -- I misread this; the intention is to remove just the option and default it to true instead.

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:

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.

Related to #379686 (closed)

Edited by Matthias Käppler

Merge request reports