我试图在Rails 4中同时服务多个请求，config.threadsafe!而Puma在Rails 3中我可以很轻松地做到这一点。
说我有这个控制器
class ConcurrentController < ApplicationController
def index
sleep 10000
end
def show
end
end
我曾经能够以puma -t 2:16 -p 3000（至少2个线程）启动puma并点击index，然后show仍然show正确渲染。
在Rails 4中，如果我尝试做同样的事情，Puma现在会锁定该index请求，并且show永远不会被渲染。当我Ctrl-C选择服务器时，Puma给了我这个错误：
Rack app error: #<ThreadError: Attempt to unlock a mutex which is locked by another thread>
我在这里缺少什么可以同时使用Rails 4？config.threadsafe!应该是不需要的（即使我尝试也不会有所作为）
我邀请您阅读config.threadsafe!本文中的配置选项。删除config.threadsafe！它将帮助您更好地了解的选项config.threadsafe!，特别是允许并发。
In Rails 4config.threadsafe!是默认设置的。
在Rails 4中，默认情况下，DEV环境中的Rack :: Lock中间件将请求包装在Mutex周围。
如果要启用并发，可以设置config.allow_concurrency=true。这将禁用Rack :: Lock中间件。如您对问题的另一个答复中所述，我不会删除它；在我看来，这简直就是骇客。
注意：如果您
config.cache_classes=true对config.allow_concurrency（Rack :: Lock请求互斥体）的分配不会生效，则默认情况下允许并发请求。如果有config.cache_classes=false，则可以设置config.allow_concurrency为true或false。在DEV环境中，您希望拥有这样的环境config.cache_classes=false config.allow_concurrency=true声明：这意味着，如果config.cache_classes = false（在dev env中是默认设置），那么我们就不会有并发请求。是不正确的。
您可以参考此答案，它使用MRI和JRuby设置了测试并发性的实验。结果令人惊讶。MRI比JRuby快。
MRI并发性实验在GitHub上进行。实验仅测试并发请求。控制器中没有竞争条件。但是，我认为实现上述文章中的示例来测试控制器中的竞争条件并不是很困难。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句