|  Richard Belleville
				
				7dccc07c2a
				Start writing README | 6 jaren geleden | |
|---|---|---|
| .. | ||
| test | 6 jaren geleden | |
| BUILD.bazel | 6 jaren geleden | |
| README.md | 6 jaren geleden | |
| client.py | 6 jaren geleden | |
| hash_name.proto | 6 jaren geleden | |
| server.py | 6 jaren geleden | |
RPCs may be cancelled by both the client and the server.
A client may cancel an RPC for several reasons. Perhaps the data it requested has been made irrelevant. Perhaps you, as the client, want to be a good citizen of the server and are conserving compute resources.
A server is reponsible for cancellation in two ways. It must respond in some way when a client initiates a cancellation, otherwise long-running computations could continue indefinitely.
It may also decide to cancel the RPC for its own reasons. In our example, the server can be configured to cancel an RPC after a certain number of hashes has been computed in order to conserve compute resources.
It's important to remember that a gRPC Python server is backed by a thread pool with a fixed size. When an RPC is cancelled, the library does not terminate your servicer thread. It is your responsibility as the application author to ensure that your servicer thread terminates soon after the RPC has been cancelled.
In this example, we use the ServicerContext.add_callback method to set a
threading.Event object when the RPC is terminated. We pass this Event object
down through our hashing algorithm and ensure to check that the RPC is still
ongoing before each iteration.
Initiating a cancellation from the server side is simpler. Just call
ServicerContext.cancel().