Changes between Version 46 and Version 47 of rpc_implementation

Timestamp:

Oct 4, 2019, 11:53:04 AM (5 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -56 +56 @@
 1. blocks and deschedule, waiting to be re-activated by the server thread when the server completed the requested service.
 
-For each RPC service type XYZ, ALMOS-MKH defines a specific ''rpc_xyz_client()'' function that performs the 3 first tasks, and calls the generic ''rpc_send()'' function to perform the three last tasks.
+For each RPC service type XYZ, ALMOS-MKH defines a specific ''rpc_xyz_client()'' function that performs the 3 first tasks, and calls the generic ''rpc_send()'' function in ''blocking" mode to perform the three last tasks.
 
 On the server side, a  kernel RPC thread is activated at the next scheduling point on the selected server core, as soon as the RPC_FIFO is non-empty. This server thread executes the following tasks:
@@ -81 +81 @@
 1. blocks and deschedule, waiting to be re-activated by the last server thread when it completed the requested service.
 
-The tasks 4 and 5 can be done, for each target server, by the generic ''rpc_send()'' function.
+The client thread calls the  generic ''rpc_send()'' function in ''non-blocking'' mode  to perform tasks 4 and 5.
+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.
 
-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.
+The behavior on the server side is not modified for a parallel RPC.
 
 == 6) Pool of RPC servers ==