[SERVER-30838] Remove "_inlock" function name usage Created: 25/Aug/17 Updated: 23/Jul/19 Resolved: 23/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Querying, Replication, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Nathan Myers | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
The server has 1228 mentions of "_inlock" functions in 133 files, including declarations, calls, and comments. These mentions should be transitioned to take/pass a mongo::WithLock argument, instead, as defined in util/concurrency/with_lock.h, to improve static error detection. Adoption can be incremental, per function, per file, or per subsystem. Because usage of the "*_inlock" naming convention is primarily confined to private member functions, uses of any particular such name are confined to a few files, most commonly two. In any case, no new "_inlock" functions should be created. |
| Comments |
| Comment by Nathan Myers [ 25/Sep/17 ] |
|
push d7aca6435e8 above does everything under mongo/s/. Everything under db/s was done by the original patch for |
| Comment by Githook User [ 25/Sep/17 ] |
|
Author: {'email': 'nathan.myers@10gen.com', 'name': 'Nathan Myers', 'username': 'nathan-myers-mongo'}Message: |
| Comment by Eric Milkie [ 25/Aug/17 ] |
|
There could very well be, but I am not personally aware of it. |
| Comment by Nathan Myers [ 25/Aug/17 ] |
|
I didn't see a way for preventing new uses to be a work item, beyond posting an announcement somewhere for the information of code reviewers. Is there a way to instrument lint to do that? |
| Comment by Eric Milkie [ 25/Aug/17 ] |
|
It sounds like there are two separate work items suggested by the description of this ticket: remove all current uses of _inlock, and prevent new uses of _inlock. Should these be separate tickets? |