kotovalexarian-likes-github/puma--puma
1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00
Code Releases Activity

Update class docs for Reactor

Browse source
This commit is contained in:
schneems 2018-05-01 11:19:50 -05:00
parent ea79d42a1c
commit 0737bb612c
1 changed files with 12 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
lib/puma/reactor.rb
View file

@ -6,21 +6,24 @@ module Puma
#
# The Reactor object is responsible for ensuring that a request has been
# completely received before it starts to be processed. This may be known as read buffering.
# If this is not done and no other read buffering is performed (such as by an application) server
# such as nginx then the application would be subject to a slow client attack.
# If read buffering is not done, and no other read buffering is performed (such as by an application server
# such as nginx) then the application would be subject to a slow client attack.
#
# For a graphical representation see [architecture.md](https://github.com/puma/puma/blob/master/docs/architecture.md#connection-pipeline).
# For a graphical representation of how the reactor works see [architecture.md](https://github.com/puma/puma/blob/master/docs/architecture.md#connection-pipeline).
#
# A request comes into a `Puma::Server`, it is then passed to the reactor.
# ## Reactor Flow
#
# A request comes into a `Puma::Server` instance, it is then passed to a `Puma::Reactor` instance.
# The reactor stores the request in an array and calls `IO.select` on the array in a loop.
#
# When the request is written to by the client then the `IO.select` will "wake up" and
# return the references to any objects that caused it to "wake". The reactor
# then loops through each of these request objects, sees if they're complete. If they
# are complete (have a full header and body) then it passes the request to a thread pool
# where a "worker thread" can run the the application's Ruby code against the request.
# then loops through each of these request objects, and sees if they're complete. If they
# have a full header and body then the reactor passes the request to a thread pool.
# Once in a thread pool, a "worker thread" can run the the application's Ruby code against the request.
#
# If the request is not complete then it stays in the array and the next time any
# data is written to it the loop is woken up and it is checked for completeness again.
# If the request is not complete, then it stays in the array, and the next time any
# data is written to that socket reference, then the loop is woken up and it is checked for completeness again.
#
# A detailed example is given in the docs for `run_internal` which is where the bulk
# of this logic lives.