Apple engineers have pointed out that OSSpinLocks are vulnerable to live locking
on iOS in cases of priority inversion:
. http://mjtsai.com/blog/2015/12/16/osspinlock-is-unsafe/
. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000372.html
- Use a dispatch_semaphore_t within the extension registry.
- Use a dispatch_semaphore_t for protecting autocreation within messages.
- Drop the custom/internal GPBString class since we don't have really good
numbers to judge the locking replacements and it isn't required. We can
always bring it back with real data in the future.
This will allow us to like to specific snippets of code in the
documentation. I plan to create a tutorial similar to the C# tutorial
https://developers.google.com/protocol-buffers/docs/csharptutorial
Since that tutorial has sections for populating a proto, parsing, and
serializing, I made a region for each of these for Go. To make the
populating sample more self-contained, I refactor the listing example
slightly.
This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.
Other plausible designs:
- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
Generated code changes follow in the next commit.
- Let Xcode update the projects, schemes, and info.plists.
- Add workaround for shallow analyzer issues in current Xcode versions (deep analyze gets things correct).
- Tweak the Swift based tests to avoid warnings from Xcode 7's XCTest using optionals for autoenclosure results.
- No longer tag the ObjC iOS travis test as flaky, xctool seems to manage the simulator pretty well.
This is adapted from the branch of @xfxyjwf at:
494716a682
and should solve the protobuf compilation problem against nvcc.
Tested against nvcc 6.5 and 7.0.
