Set middleware_mutex when middleware/adapter classes are defined#1074
Set middleware_mutex when middleware/adapter classes are defined#1074technoweenie wants to merge 4 commits intomainfrom
Conversation
d51a6c6 to
fb085ae
Compare
|
Another option is to just define
Just thoughts FYI. |
|
When I read your comment, I took it as something like this: diff --git a/lib/faraday/adapter.rb b/lib/faraday/adapter.rb
index 535ecb5..565c490 100644
--- a/lib/faraday/adapter.rb
+++ b/lib/faraday/adapter.rb
@@ -33,7 +33,7 @@ module Faraday
def inherited(subclass)
super
- subclass.middleware_mutex
+ subclass.init_mutex
subclass.supports_parallel = supports_parallel?
end
end
diff --git a/lib/faraday/middleware_registry.rb b/lib/faraday/middleware_registry.rb
index 692d0a0..51e664f 100644
--- a/lib/faraday/middleware_registry.rb
+++ b/lib/faraday/middleware_registry.rb
@@ -8,7 +8,7 @@ module Faraday
module MiddlewareRegistry
def self.extended(klass)
super
- klass.middleware_mutex
+ klass.init_mutex
end
# Register middleware class(es) on the current module.
@@ -96,9 +96,12 @@ module Faraday
raise(Faraday::Error, "#{key.inspect} is not registered on #{self}")
end
+ def init_mutex
+ @middleware_mutex = Monitor.new
+ end
+
def middleware_mutex(&block)
puts "#{self}: middleware_mutex" if @middleware_mutex.nil?
- @middleware_mutex ||= Monitor.new
@middleware_mutex.synchronize(&block) if block
endOr did you mean: diff --git a/lib/faraday/middleware_registry.rb b/lib/faraday/middleware_registry.rb
index 692d0a0..51e664f 100644
--- a/lib/faraday/middleware_registry.rb
+++ b/lib/faraday/middleware_registry.rb
@@ -8,7 +8,7 @@ module Faraday
module MiddlewareRegistry
def self.extended(klass)
super
- klass.middleware_mutex
+ klass.init_mutex
end
# Register middleware class(es) on the current module.
@@ -96,9 +96,12 @@ module Faraday
raise(Faraday::Error, "#{key.inspect} is not registered on #{self}")
end
+ def init_mutex
+ @middleware_mutex = Monitor.new
+ end
+
def middleware_mutex(&block)
puts "#{self}: middleware_mutex" if @middleware_mutex.nil?
- @middleware_mutex ||= Monitor.new
@middleware_mutex.synchronize(&block) if block
end
|
|
And yes something like that. |
|
Rephrasing, losing the if: diff --git a/lib/faraday/middleware_registry.rb b/lib/faraday/middleware_registry.rb
index 692d0a0..5fefaff 100644
--- a/lib/faraday/middleware_registry.rb
+++ b/lib/faraday/middleware_registry.rb
@@ -8,7 +8,7 @@ module Faraday
module MiddlewareRegistry
def self.extended(klass)
super
- klass.middleware_mutex
+ klass.init_mutex
end
# Register middleware class(es) on the current module.
@@ -96,10 +96,13 @@ module Faraday
raise(Faraday::Error, "#{key.inspect} is not registered on #{self}")
end
+ def init_mutex
+ @middleware_mutex = Monitor.new
+ end
+
def middleware_mutex(&block)
puts "#{self}: middleware_mutex" if @middleware_mutex.nil?
- @middleware_mutex ||= Monitor.new
- @middleware_mutex.synchronize(&block) if block
+ @middleware_mutex.synchronize(&block)
end
def fetch_middleware(key)
|
|
Does Also does it still work if you make it |
|
If I make it Will make an attempt re: That leads to: (Since I'm calling it in those |
|
I need to check it. |
This is an attempt to fix #1065 by calling
#middleware_mutexwhen the classes are defined. This should prevent@middleware_mutexfrom being undefined when aFaraday::Connectioninstance is used in a multi-threaded environment.Right now, the proper way to build a
Faraday::Connectionfor use in a multi-threaded environment should look something like this:faraday/lib/faraday/rack_builder.rb
Lines 156 to 168 in d51a6c6
Faraday::Connection#appis delegated toFaraday::RackBuilder#app, which does the following:Faraday::Requestmiddleware registry to load:somethingFaraday::Responsemiddleware registry to load:or_otherFaraday::Adaptermiddleware registry to load:some_http_clientFaraday::RackBuilderinstance from changing the middleware chain (conn.builder.handlers)At this point, it should be safe to use shared connection object across multiple threads. But, I don't know how often it's used like this, so there are likely some more bugs.
I also have another larger solution in mind that requires some refactoring. I'll publish once I have it working.