A process may fork after invoking grpc_init() and use gRPC in the child
if and only if the child process first destroys all gRPC resources
inherited from the parent process and invokes grpc_shutdown().
Subsequent to this, the child will be able to re-initialize and use
gRPC. After fork, the parent process will be able to continue to use
existing gRPC resources such as channels and calls without interference
from the child process.
To facilitate gRPC Python applications meeting the above constraints,
gRPC Python will automatically destroy and shutdown all gRPC Core
resources in the child's post-fork handler, including cancelling
in-flight calls (see detailed design below). From the client's
perspective, the child process is now free to create new channels and
use gRPC.
The test modules were not under pylint jurisdiction,
and actual bugs have been found in tests that would
have been prevented had we run static analysis on
the test code as we do on the core modules.
This is the first step to enable pylint on tests.
Due to numerous warnings since the code is not ready
and needs refactoring, a new `.pylintrc`
specific to tests is added that suppresses a number
of valid warnings. The goal is stepwise elimination
of each class of warning while refactoring the code
such that it will not emit any warnings in future
commits, always keeping the sanity checks passing
and keeping the disruption minimal.
In _server.py start_server_batch_result is removed because
start_server_batch can only ever fail as a result of a programming
defect in gRPC Python and not the application. This differs from some
analogous-appearing points in _channel.py where the result of
start_client_batch is checked because at those points it is possible
for a failure to indicate a programming defect on the part of the
application.
Pylint is only enabled for "grpcio/grpc" package,
and various specific checks that currently fail are disabled,
each with a respective TODO item in the .pylintrc file.