Changes between Version 40 and Version 41 of rpc_implementation

Timestamp:

Feb 4, 2019, 2:09:19 PM (5 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -81 +81 @@
 The tasks 4 and 5 can be done, for each target server, by the generic ''rpc_send()'' function.
 
-If the RPC service does not return values (no ''out'' arguments), it is possible to save memory on the client side,:w
- and use an unique, shared, RPC descriptor.
+When the RPC "in" arguments values are equal for all target clusters, and there is  no ''out'' arguments, it is possible to save memory on the client side, and use an unique, shared, RPC descriptor.
 
 == 6) Pool of RPC servers ==
 
 In order to avoid deadlocks, for each core, ALMOS-MKH defines a private pool of RPC threads  associated to one single RPC_FIFO[i,k]. 
-If a given RPC thread extracted request[i] from the FIFO, but is blocked, waiting for a shared resource, the next request[i+i] in the FIFO can be extracted and handled by another RPC thread. In that case, the blocked RPC thread T releases the FIFO ownership before blocking and descheduling. This RPC thread T will complete the current RPC request when the blocking condition is solved, and the thread T is rescheduled. If the RPC FIFO is not empty, another RPC thread T' will be scheduled to handle the pending RPC requests. If all existing RPC threads are blocked, a new RPC thread is dynamically created.
+If a given RPC thread extracted request[i] from the FIFO, but is blocked, waiting for a shared resource, the next request[i+i] in the FIFO can be extracted and handled by another RPC thread. In that case, the blocked RPC thread T releases the FIFO ownership before blocking and descheduling. This RPC thread T will complete the current RPC request when the blocking condition is solved, and the thread T is rescheduled. At any time, only one RPC thread has the FIFO ownership and can consume RPC requests from the FIFO. 
 
-At any time, only one RPC thread has the FIFO ownership and can consume RPC requests from the FIFO. 
+The RPC threads are dynamically created - on demand - by the scheduler: When the RPC FIFO is not empty, an "idle"  RPC thread is scheduled to handle the pending RPC requests. If all existing RPC threads are blocked, a new RPC thread is dynamically created by the scheduler (in the ''shed_rpc_activate()'' function).
 
 Therefore, it can exist for each RPC_FIFO[i,k] a variable number M of RPC threads: the running one is the FIFO owner, and the (M-1) others are blocked on a wait condition.
-This number M can temporarily exceed the CONFIG_RPC_THREAD_MAX value, but the exceeding server threads are destroyed when the temporary overload is solved.
+This number M can temporarily exceed the CONFIG_RPC_THREAD_MAX value, but the exceeding server threads are destroyed when the temporary overload is solved, by the ''rpc_thread_func()'' function itself.
 
 == 7) How to define a new RPC ==