Is purely a refactor - the logic remains exactly the same
There are a few renames:
process_messages -> run_loop
process_messages is confusing since we already have a .process method and its not clear what the difference is.
the difference is that it runs the chain in an infinite loop. So better to name it after the run method that calls it and add _loop
send_receive_chain_loop could also be a reasonable name
process -> send_receive_chain
it takes requests as args and sends them down the chain, sending the response to the client, so this rename makes it clear what exactly is being processed.
The main point of the PR is to move sending of responses into send_receive_chain.
To achieve this the CloseReason enum is introduced, currently only the existence of the CloseReason is meaningful so there is only one variant.
The existence of the CloseReason indicates to run_loop whether to terminate the loop or not.
CloseReason will be extended in #1722 to have unique handling for different close reasons.
This PR:
There are a few renames:
process_messages
->run_loop
.process
method and its not clear what the difference is.run
method that calls it and add_loop
send_receive_chain_loop
could also be a reasonable nameprocess
->send_receive_chain
The main point of the PR is to move sending of responses into
send_receive_chain
. To achieve this theCloseReason
enum is introduced, currently only the existence of theCloseReason
is meaningful so there is only one variant. The existence of theCloseReason
indicates torun_loop
whether to terminate the loop or not.CloseReason
will be extended in #1722 to have unique handling for different close reasons.