More generic configuration system is introduced in order to i) unify the
way how modules access the configurations instead of using low-level
get/setenv functions and ii) enable the customization for where configuration
is stored. This could be extended to support flag, file, etc.
Default configuration system uses environment variables as before so
basically this is expected to work just as it did. This behavior can
change by redefining GPR_GLOBAL_CONFIG_DEFINE_*type* macros.
* Migrated configuration
GRPC_CLIENT_CHANNEL_BACKUP_POLL_INTERVAL_MS
GRPC_EXPERIMENTAL_DISABLE_FLOW_CONTROL
GRPC_ABORT_ON_LEAKS
GRPC_NOT_USE_SYSTEM_SSL_ROOTS
alignment options (for cache-alignment).
We shrink by:
1) Removing an unnecessary zone pointer.
2) Replacing gpr_mu (40 bytes when using pthread_mutex_t) with
std::atomic_flag.
We also header-inline the fastpath alloc (ie. when not doing a zone
alloc) and move the malloc() for a zone alloc outside of the mutex
critical zone, which allows us to replace the mutex with a spinlock.
We also cache-align created arenas.
It turns out that the code generation for "with gil" is a bit more
complicated than the logic for re-obtaining the gil at the end of
"with nogil." This is because PyGILState_Ensure seems to, during
interpreter finalization, think it needs to call a new thread
(resulting in a call to cpython new_threadstate) which then segfaults.
Because "with nogil" knows that, prior to executing, it already had
the gil, it doesn't need to set up as much state, and thus the segfault
does not occur.
To avoid this, we just only use "with nogil" within the infinite loop,
and then end the "nogil" block before we check signals. This avoids
needing any "with gil" call at all.
I was able to reliably reproduce the segfault within a few minutes
before the patch by running a binary in a loop (with py3) while
maxing out my machines cpu usage. After the patch, I have not
been able to reproduce the segfault after two hours.
Note that this race can only occur when the user does not properly
clean up all their channels, and is relying on garbage collection to
do so (which isn't guaranteed). However, we want to avoid a segfault
on failure to close because this isn't a good user error and makes it
hard to debug.
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.
Lidi Zheng
Srini Polavarapu
Esun Kim
Richard Belleville
Mehrdad Afshari
murgatroid99
Alexander Polcyn
Srini Polavarapu
Yash Tibrewal
Arjun Roy
Muxi Yan
Mark D. Roth
Fabian Holler
Jared Hance
Evan Jones
Yihua Zhang
Vijay Pai