Ruby's `require_relative` method currently converts paths to absolute
paths. This idiosyncrasy means that the implementation of the require
for the distributed shared library works, however the semantics do not
mesh with the semantics of `require_relative`.
This is an issue when you redefine `require_relative` and follow the
semantics of the method, as [derailed_benchmarks does][1]. This means
that any project that uses `grpc` also cannot use that project (which
I will also be patching).
In the event that a new version of Ruby follows the semantics of the
method (whether or not that is likely), this will break as well.
By switching to `require` here instead of `require_relative`, we
maintain the functionality but do not use a semantically incompatible
method to do so.
[1]: 1b0c425720/lib/derailed_benchmarks/core_ext/kernel_require.rb (L24-L27)
Previously, signal handlers were only given a chance to run upon receipt of an
entry in the RPC stream. Since there is no time bound on how long that might
take, there can be an arbitrarily long time gap between receipt of the signal
and the execution of the application's signal handlers.
Signal handlers are only run on the main thread. The cpython implementation
takes great care to ensure that the main thread does not block for an
arbitrarily long period between signal checks.
Our indefinite blocking was due to wait() invocations on condition variables
without a timeout.
This changes all usages of wait() in the the channel implementation to use a
wrapper that is responsive to signals even while waiting on an RPC.
A test has been added to verify this.
Tests are currently disabled under gevent due to
https://github.com/grpc/grpc/issues/18980, but a fix for that has been
found and should be merged shortly.