gh-129200: Add locking to the iOS testbed startup sequence. #130564
Conversation
|
!buildbot iOS |
|
🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit bc647db 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F130564%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
freakboy3742
requested review from
ned-deily
and removed request for
erlend-aasland
| class SimulatorLock: | ||
| # An fcntl-based filesystem lock that can be used to ensure that | ||
| def __init__(self, timeout): | ||
| self.filename = Path(tempfile.gettempdir()) / "python-ios-testbed" |
There was a problem hiding this comment.
Does the lock need to be system-wide rather than just for a particular user? If so, the use of tempfile.gettempdir() can be problematic here. As documented, it checks first for a TMPDIR environment variable and it appears that usually on macOS TMPDIR is set to a user-specific temp directory, for example:
>>> tempfile.gettempdir()
'/var/folders/sn/0m4rnbyj2z1byjs68sz838300000gn/T'
There was a problem hiding this comment.
As best as I can make out, the lock only needs to be per user. If I start a simulator on one user's account, then use Fast User Switching to move to a second user's account, the simulator on the first user's account doesn't show on the second.
|
Thanks @freakboy3742 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
…thonGH-130564) Add a lock to ensure that only one iOS testbed per user can start at a time, so that the simulator discovery process doesn't collide between instances. (cherry picked from commit 9211b3d) Co-authored-by: Russell Keith-Magee <[email protected]>
|
GH-130657 is a backport of this pull request to the 3.13 branch. |
…H-130564) (#130657) Add a lock to ensure that only one iOS testbed per user can start at a time, so that the simulator discovery process doesn't collide between instances. (cherry picked from commit 9211b3d) Co-authored-by: Russell Keith-Magee <[email protected]>
…thon#130564) Add a lock to ensure that only one iOS testbed per user can start at a time, so that the simulator discovery process doesn't collide between instances.
In order to stream iOS testbed output, it is necessary to run a log stream on the iOS system log. This requires identifying the simulator whose logs need to be streamed.
The Xcode project is responsible for starting the simulator, and doesn't report the identity of the simulator. To work around this, a polling mechanism is used to identify when a new simulator is started. However, this polling mechanism is fragile if 2 testbed runs are started on the same machine at near the same time, as 2 new simulator instances may be created in rapid succession. This causes the log streamer to be unable to identify which simulator is associated with which testbed run.
This PR adds a system-wide locking mechanism around the creation of simulator instances. The lock is acquired just before the first call to obtain the list of simulators; it is released as soon as a new simulator is identified. If two test runs are started at the same time, one will acquire the lock; the other will wait until the first run releases the lock. In this way, multiple testbed runs can be started at the same time, at the cost of a slightly delayed startup of the second testbed run. In my testing, the delay is approximately 1 minute when 2 runs are started; this reflects the time to compile the testbed and start a simulator device. A timeout of 10 minutes is enforced on waiting for the lock.
There is a related race condition in the
make testiostarget; if two tests are started in the same second, they'll generate the same temporary filename for the cloned testbed project. This PR adds the parent PID to the testbed clone name to ensure that tests started in the same second are unique.