Implement the Mac prefs lock by polling ownership of a Mach service.
If the service has a matching port with a receive right in userspace, the task with the receive right owns the lock. If the service is not assigned, the lock is free. This implementation polls to attempt to acquire the lock, using a constant service name and constant polling interval. Further development could fetch these values from another source of truth (a file of constants, compiler macros, options loaded at runtime, etc.) or use bootstrap_look_up and mach_port_request_notification to find the owner of the lock and wait for the lock to be released. This change includes two broad changes to preexisting unit tests, due to issues revealed with those tests while developing this CL: * app_server_unittest.cc included tests where the AppServer lived in the same scope as test code that generates a reference to the Global Prefs Object, which requires the prefs lock. This results in deadlock with a non-reentrant implementation of a prefs lock, since the AppServer owns that lock at that time. This CL introduces scopes to deallocate the AppServer instance before the test itself grabs the global prefs lock. * prefs_unittest.cc marked out all the lock tests as Windows-only. Now that there is a Mac lock, this limitation does not need to exist. However, one of its tests explicitly checked that the lock supports reentrancy within a thread (while another verified that it bans reentrancy across threads). This test has been deleted, after discussion with teammates where we decided that a non-reentrant lock is desired. Change-Id: I513cb67d1c3a12b2b0c01b532a9af10ae2233530 Bug: 1135692 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453800Reviewed-by:Joshua Pawlicki <waffles@chromium.org> Reviewed-by:
Sorin Jianu <sorin@chromium.org> Commit-Queue: Adam Norberg <norberg@google.com> Cr-Commit-Position: refs/heads/master@{#815825}
Showing
Please register or sign in to comment