Implement the minimal stuff for making a unary call with the new
experimental gRPC Python implementation for Asyncio, called Aio.
What has been added:
- Minimal iomgr code for performing the required network and timer
calls.
- Minimal Cython code implementing the channel, call and the callback
context.
- Minimal Python code that mimics the synchronous implementation but
designed to be asynchronous.
Testing considerations:
Tests have to be executed using the `GRPC_ENABLE_FORK_SUPPORT=0`
environment variable for skipping the fork handles installed by
the core library. This is due to the usage of a syncrhonous server
used as a fixture executed in another process.
Co-authored-by: Manuel Miranda <manuel.miranda@skyscanner.net>
Co-authored-by: Mariano Anaya <mariano.anaya@skyscanner.net>
Co-authored-by: Zhanghui Mao <zhanghui.mao@skyscanner.net>
Co-authored-by: Lidi Zheng <lidiz@google.com>
It's not the default with older Apple clang builds
and without it c++11 features don't work on at least OS X 10.7:
./src/core/lib/gprpp/ref_counted.h:28:10: fatal error: 'atomic' file not found
#include <atomic>
^~~~~~~~
I manually tested it on macOS 10.11 image and there was not a
regression.
This should fix the "Artifact Build MacOS (internal CI)" test failure.
* Use templates instead of generating them every time
* Theme changed
* Add grpc_* modules
* APIs grouped
* No documentation for class members without docstring
* Add docstring for status code
Add an environmental variable GRPC_PYTHON_DISABLE_LIBC_COMPATIBILITY that unsets the GPR_BACKWARDS_COMPATIBILITY_MODE macro during the C++ build.
The reason I'm interested in this to allow gpr_now to use the vdso rather than a syscall to read the time.
Modern Python dependancy tooling as defined in PEP-508 should use environment markers for Python version specific requirements.
This allows the `grpcio` package to work with dependancy resolvers like poetry
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_CARES env variable, the third party cares code
is not compiled. Instead, the cares shared library installed on the
system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_ZLIB env variable, the third party zlib code
is not compiled. Instead, the zlib shared library installed on the
system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL env variable, the third party
boringssl code is not compiled. Instead, the openssl shared library
installed on the system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.