From 00b3d9f52f965cad6e653ceb8f5c21a96742c55a Mon Sep 17 00:00:00 2001
From: Vipul A M <vipulnsward@gmail.com>
Date: Mon, 20 Nov 2017 19:19:00 +0530
Subject: Pass over Execution guide[ci skip]

---
 guides/source/threading_and_code_execution.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/guides/source/threading_and_code_execution.md b/guides/source/threading_and_code_execution.md
index 1c7d61a29c..3d3d31b97e 100644
--- a/guides/source/threading_and_code_execution.md
+++ b/guides/source/threading_and_code_execution.md
@@ -57,7 +57,7 @@ In a default Rails application, the Executor callbacks are used to:
 Prior to Rails 5.0, some of these were handled by separate Rack middleware
 classes (such as `ActiveRecord::ConnectionAdapters::ConnectionManagement`), or
 directly wrapping code with methods like
-`ActiveRecord::Base.connection_pool.with_connection do`. The Executor replaces
+`ActiveRecord::Base.connection_pool.with_connection`. The Executor replaces
 these with a single more abstract interface.
 
 ### Wrapping application code
@@ -93,7 +93,7 @@ with an `executor` option. Despite the name, it is unrelated.
 The Executor is safely re-entrant; if it is already active on the current
 thread, `wrap` is a no-op.
 
-If it's impractical to physically wrap the application code in a block (for
+If it's impractical to wrap the application code in a block (for
 example, the Rack API makes this problematic), you can also use the `run!` /
 `complete!` pair:
 
@@ -266,7 +266,7 @@ end
 To prevent this deadlock, the outer thread can `permit_concurrent_loads`. By
 calling this method, the thread guarantees it will not dereference any
 possibly-autoloaded constant inside the supplied block. The safest way to meet
-that promise is to put it as close as possible to the blocking call only:
+that promise is to put it as close as possible to the blocking call:
 
 ```ruby
 Rails.application.executor.wrap do
-- 
cgit v1.2.3