Context detail messages are Unicode strings in both the implementation and
specification. Fix the documentation to make this clearer. The
specification for the Status-Message response field says "Status-Message is
[...] a Unicode string [...] encoded as UTF-8" [1]. The implementation
seems to call _common.encode(), so anything that is UTF-8 encodable works.
For example:
context.set_code(grpc.StatusCode.ABORTED)
context.set_details('emoji error: \U0001F600')
Correctly returns a smiley face emoji to the client.
GCC allows this, but notably clang does not. Other systems,
like FreeBSD and some Linux distros ship with clang as default
compiler. While here, switch the approach to filtering out std
flag since the make workaround relies on GNU make syntax and
'make' binary could be bmake and/or gmake could be absent.
The idea to filter the flags was taken from an answer to this
Stack Overflow question:
https://stackoverflow.com/questions/15527611/how-do-i-specify-different-compiler-flags-in-distutils-for-just-one-python-c-ext
grpc_handshake is renamed to GrpcHandshake, using C++ class definitions
instead of C-style vtable classes. Update callers to use new interfaces.
We use RefCountedPtr to simplify reference tracking.
Python 3 exceptions include a `__traceback__` attribute that includes
refs to all local variables. Saving the exception results in leaking
references to the, among other things, the Cython grpc_call wrapper and
prevents garbage collection and release of core resources, even after
the server is shutdown.
See
https://www.python.org/dev/peps/pep-3134/#open-issue-garbage-collection