Prevent concurrent read and writes to the API config
Review Request #9834 — Created March 26, 2018 and submitted
Information | |
---|---|
brennie | |
rb-gateway | |
master | |
|
|
9839 | |
3ff0120... | |
Reviewers | |
rb-gateway | |
Previously it was possible for the API's configuration to be modified
while it was serving a request, resulting in data races and undefined
behaviour if we read the repository map part-way through a modification.Now, we wrap all modification to the configuration with a
RWMutex
. It
normal operation, we only acquire the mutex for reading once -- done by
api.Serve()
(which is now the replacement for creating an
http.Server
and managing it), which will be released when we finish
serving. Setting the configuration now requires write-access to the lock
(so that we cannot concurrently be serving a request and update the
configuration).Since we want to maintain these guarantees in unit tests without running
an actual HTTP server,api.ServeHTTP()
now acquires the read portion
of the lock before serving a request. However, this function is now only
used in unit tests --api.Serve()
uses therouter
as the handler
instead of itself so that it doesn't constantly acquire and release
locks while serving requests.
Ran unit tests.
Made HTTP requests against rb-gateway and saw correct responses.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 2 (+35 -16) |
Checks run (2 succeeded)
Change Summary:
Rebasing all patches.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 3 (+35 -16) |
Checks run (2 succeeded)
Change Summary:
Return
*http.Server
so we aren't getting a copy and can close the correct server.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 4 (+35 -16) |
Checks run (2 succeeded)
Change Summary:
Turns out you need to commit before posting >.>
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 5 (+35 -16) |
Checks run (2 succeeded)
Change Summary:
Addressed David's issues.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 6 (+35 -16) |