tree ace694369d3eaefcea245a20698e2e188965e6b5
parent 63105e5dc89d8404969959ccfa13927c2dcf26da
author Joe Tsai <joetsai@digital-static.net> 1555442092 -0700
committer Joe Tsai <thebrokentoaster@gmail.com> 1555452246 +0000

proto: unmarshal extensions eagerly

Prior to this CL, Go did not eagerly unmarshal extension fields.
The unmarshaling was done when GetExtension was called.
The prior behavior has always been problematic:
* This is incorrect since we are not validating that extensions
are valid upon the initial unmarshal, which is a property of correctness
that C++ and Java provide.
* Usage is racy. GetExtension is a mutating operation since it can
transform some bytes in the unknown fields to become extension fields.
Thus, concurrent read-only operations with GetExtension is racy.
In v1, we added a lock around the extension map to try and avoid a race,
but this is just a facade. This fixes a race condition in terms of the
Go memory model, but it is still racy since a local operation can still
observe the effects of a remote GetExtension operation.
* The API is clunky since delayed unmarshaling means that GetExtension
needs to deal with possible unmarshal errors.

We make extensions eagerly unmarshaled to avoid all of these problems.

Change-Id: Iafccf2aeaa839c0d3f88ca18bd84af481e9b1662
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/172399
Reviewed-by: Damien Neil <dneil@google.com>