| Commit message (Collapse) | Author | Age |
|\
| |
| | |
credentials: call grpc_init/grpc_shutdown when created/destroyed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This addresses https://github.com/grpc/grpc/issues/17001. Prior to
https://github.com/grpc/grpc/pull/13603, our credentials cython objects
used grpc_initi() and grpc_shutdown() on creation and destruction. These are
now managed differently, but the grpc_init() and grpc_shutdown() calls
are still required. See the MetadataCredentialsPluginWrapper in C++,
which extends the GrpcLibraryCodegen class to ensure that grpc_init()
and grpc_shutdown() are called appropriately.
Without this, we can deadlock when a call to grpc.Channel#close()
triggers grpc_shutdown() to block and wait for all timer threads to
finish: one of these timer threads may end up unreffing the subchannel
and triggering grpc_call_credentials_unref, which will jump back into
Cython and hang when it tries to reacquire the GIL.
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
This worked fine with CPython, but the condition
was always evaluated to False with Pypy, causing
bugs down the road.
Tested with Pypy 6.0.
|
|
|
|
|
|
| |
a verification callback option.
These options are not yet exposed to languages outside of core.
|
|
|
|
|
|
|
|
| |
This change adds an experimental ssl_session_cache_lru function to the
Python API that returns an encapsulated grpc_ssl_session_cache (#14483).
Python clients may use this object as an argument for the
grpc.ssl_session_cache channel option if they wish to cache and resume
TLS sessions with a server.
|
| |
|
| |
|
|
|
|
|
|
| |
Rather than allocating gRPC Core memory when instantiated and
retaining it until deleted, gRPC Python's credentials objects now
offer methods to create gRPC Core structures on demand.
|
|\
| |
| | |
Elide local field by directly returning values.
|
|\ \
| | |
| | | |
Add missing const.
|
| |/ |
|
| | |
|
|/
|
|
|
| |
I should have requested this during code review of bcf083fa9099e5c919
but it slipped my mind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a secure server is configured with SSL credentials during
initialization, and those credentials will be used for the lifetime of
the server. If the user wants the server to use new credentials, the
user has to restart the server, resulting in server downtime. This
change enables the user to optionally configure the server with a
"certificiate config fetcher," such that on every new client
connection, the server will call the config fetcher before performing
the handshake, allowing the user application to optionally specify new
certificate configuration for the server to use (the fetcher can
return a "no change" and the server continues to use its current
certificate configuration).
|
|\
| |
| | |
Devolve staticmethod to ordinary function.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The gRPC Core has two styles for passing metadata: as an integer count
along with a grpc_metadata* pointer, which is used for passing metadata
into the core, and as a grpc_metadata_array, which is used for passing
metadata out of the core. The Cython layer of gRPC Python was using a
single data structure wrapping grpc_metadata_array for both purposes,
but this was complex because the core manages the slices contained in
grpc_metadata_array objects (at least those of which it is aware), so
the Cython layer had to keep track of whether or not the core was aware
of the slices it was using (and it was also defective, leaking slices).
This is solved by realigning with the Cython layer’s intended design of
mirroring as closely as possible in Python the gRPC Core API: we use
one structure for passing metadata into the core (what is now called
cygrpc.Metadata) and second, different structure for receiving metadata
out of the core (what was called cygrpc.Metadata but is now
cygrpc.MetadataArray, reflecting that it wraps the core’s
grpc_metadata_array).
All bug fixes should contain added tests preventing regression but this
doesn't because I don't know at this time how to write a does-not-leak
test for Python that fits well into our existing body of tests. Phooey.
Thanks to Dominik Janků (djanku@email.cz) for investigation and an
earlier draft of a solution.
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
Incremental changes towards PyPy support.
|
|
|
|
|
|
|
| |
When a child thread triggers __dealloc__ as part of a thread being
joined, the thread is already considered to be "joined", and so
releasing the GIL can allow the main thread to proceed to exit,
which introduces shutdown race conditions/memory leaks.
|
|
|
|
|
|
|
|
|
| |
This impacts the following APIs:
Metadata: Key is always a str, Value is bytes for binary metadata,
str otherwise
Call Details: str type
gRPC method: str type
hostname/target: str type
|
|
|
|
|
|
|
|
| |
Notable Changes:
-Convert all str types to byte types at cython layer (ascii encoding)
-Use six for packages that have different names in Python2/Python3
-By default, unit tests are compiled/run in Python2.7 and Python3.4
-Ensure MACOSX_BUILD_TARGET is at least 10.7
|
| |
|
|
|
|
| |
application handle the authentication.
|
| |
|
| |
|
|
|