| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
Appease the yapf gods
Reformat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 works around issue 15662 which is not as easy to implement as I
would prefer it to be.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes invocation-side completion queues from the _cygrpc API.
Invocation-side calls are changed to no longer share the same lifetime
as Core calls.
Illegal metadata is now detected on invocation rather than at the start
of a batch (so passing illegal metadata to a response-streaming method
will now raise an exception immediately rather than later on when
attempting to read the first response message).
It is no longer possible to create a call without immediately starting
at least one batch of operations on it. Only tests are affected by this
change; there are no real use cases in which one wants to start a call
but wait a little while before learning that the server has rejected
it.
It is now required that code above cygrpc.Channel spend threads on
next_event whenever events are pending. A cygrpc.Channel.close method
is introduced, but it merely blocks until the cygrpc.Channel's
completion queues are drained; it does not itself drain them.
Noteworthy here is that we drop the cygrpc.Channel.__dealloc__ method.
It is not the same as __del__ (which is not something that can be added
to cygrpc.Channel) and there is no guarantee that __dealloc__ will be
called at all or that it will be called while the cygrpc.Channel
instance's Python attributes are intact (in testing, I saw both in
different environments). This commit does not knowingly break any
garbage-collection-based memory management working (or "happening to
appear to work in some circumstances"), though if it does, the proper
remedy is to call grpc.Channel.close... which is the objective towards
which this commit builds.
|
| |
|
| |
|
|
|
|
|
|
| |
Rather than single classes they are now broken up into class families
with each class containing only those fields and methods that are
needed in the context in which the class is used.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This reverts commit 5e01e2ac977655aa074faf7fde0a74298f5e4c55.
|
| |
|
|
|
|
| |
... but for real this time.
|
| |
|
| |
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Some __dealloc__ methods were calling Python methods, and some
references were being dropped on the floor instead of threaded through
gRPC core.
|
|
|