-
-
Notifications
You must be signed in to change notification settings - Fork 103
This is not thread local, it is in fact fiber local. #580
Comments
See socketry/async-rspec#22 for an example of where this can be a problem. |
If I understand the docs correctly, it's suggested to use: Thread.current.thread_variable_set(:foo, 1)
Thread.current.thread_variable_get(:foo) to share the value between all fibers of the same thread. So we would have to: - Thread.current[:__rspec] ||= {}
+ Thread.current.thread_variable_get(:__rspec) || Thread.current.thread_variable_set(:__rspec, {}) Does this sound right, @ioquatix ? |
I think you should do the same as I proposed here: ruby/debug#987 Such an approach was also adopted recently by Rails. I've been an advocate of this style for a while and I think it's good to be explicit. If you want the details I am happy to write them down; LMK. So: class Thread
attr_accessor :rspec_state
end
module RSpec::Support
def self.current_state
Thread.current.rspec_state ||= {}
end
end That's assuming you will always only run one test per thread at a time. This is also the most efficient way to do TLS, i.e. it works really well with the recent work on object shapes. |
We try to avoid monkey patching as much as possible, so a solution which doesn't modify the thread class is preferred. |
I wouldn't really call this a monkey patch. This is the most efficient and correct way to add a thread-local variable (we don't have any mechanism for annotating a global variable as thread local unfortunately), it also prevents clobbering as clobbering an |
If |
I wouldn’t rely on this assumption in the long run |
The alternative is to use |
We have to figure out something that would also work on 1.8 and 1.9 |
Fix released in |
rspec-support/lib/rspec/support.rb
Line 93 in 6d33eaa
I suggest introducing an actual thread local variable, e.g.
The text was updated successfully, but these errors were encountered: