feat(ffi): Latest revision lock in go #1473
Description
Nit: I wonder if a lock would prevent stupid errors here (probably a separate issue).
An uncontended mutex is pretty cheap.
If you agree, create an issue from this.
Originally posted by @rkuris in #1466 (comment)
Especially for the latest update stuff, it seems very reasonable to provide this. I think a wider discussion about whether all necessary locking can/should be implemented in the library or given to the user, since #1466 clearly defined the concurrency requirements.
Additionally, we need to do some performance testing on whatever we decide to ensure that it doesn't degrade performance