Setting the newly added compression_level field of
grpc_op::send_initial_metadata by a server now has the effect of
applying that compression level for the subsequent call messages leaving
the server. The ultimate meaning of the level depends on the client's
supported compression algorithms.
- properly fail a Read() on a stream if we fail to parse a protobuf
- fix an ordering problem with the chttp2 transport global lock, whereby
a sequence of two operations could be swapped - this resulted in
slices being returned to the upper layers in the wrong order,
corrupting data
whenever appropriate so as to avoid any unintentional free-before-use
problems.
Potential performance issue: this triggers an additional allocation
for each Async call initiation, along with the cost of ref-counting
shared_ptr . But this is worth it for the additional safety provided
here without any change to the exposed C++ API.
Specifically:
Receiving trailing and initial metadata had to be published in
lock-step.
=> If we wanted trailing metadata, we might not get initial metadata processed
until messages arrived.
=> Compression code had no idea what codec to use.
To fix it, publish initial metadata as soon as it's ready (this is a
transport API change).
Requires changes to grpc_call to ensure ordering in processing initial
metadata and messages (one may be delayed).
Exposed at least some bugs in C++ where we never read initial metadata.
I expect at least one more similar bug.