The current thread is moved to the 'running'mode, temporarily blocking the thread. So, the thread will not be accessible by any other request that tries to do so.
- Reloader: The Reloader functions similarly to the Executor. The code that is to be protected is wrapped before another request is hit. This is used in scenarios where application code is invoked multiple times by any long-running process. Most often, in Rails, the web requests and Active Jobs are by default wrapped. So the Reloader is rarely used.
A Reloader is employed when there is a need to reload the application. When the requested condition asks for reloading, the Reloader delays the application reload until it is secure. And for scenarios where application reloads are mandated, the Reloader waits until the current block is executed and allows the reload. Thus, the code is protected from errors.
The 'to_run
' and 'to_complete
' callbacks are used by the Reloader also.
A class unloadis involved in the Reloader process. Here, all of the auto-loaded classes are removed and set ready to be further loaded. The application reload is to happen only before or after the class unload, and so, the two additional callbacks of Reloader are 'before_class_unload
' and 'after_class_unload
'.
Executor and Reloaders are used by the Rails framework components as well. ActionDispatch::Executor
and ActionDispatch::Reloader
are included in the default application stack. Whenever there is a code change, the Reloader serves a fresh copy of the application for an HTTP request. Active Job feature also utilizes Reloaders, whereas Action Cable uses Executor. Action Cable also uses the before_class_unload of Reloader to disconnect all the connections.
As discussed, code concurrency is handled by default with the threaded active jobs and action cables features of Rails codes. With recent Rails updates, Executors and Reloaders are also added to improve the code concurrency handling.
Also, check out 7 Ruby Gems to keep in your toolbox.