You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In that example we have two tests that use the clipboard. When run in parallel the tests both writing to and reading from the clipboard have an obvious race condition which causes intermittent failures. Our usual approach of partitioning the state doesn't work here because it's OS-level global state; partitioning would be equivalent to requiring tests to be run single-process-per-OS-instance.
To solve this the obvious abstract requirement is some way to annotate which tests are known to require the same shared state. For example: <meta name=state content=clipboard>
Functionally it would then be up to the runner to ensure that multiple tests declaring the same state requirements don't run in parallel. This could be achieved by each type of state being associated with a mutex that must be acquired before starting the test (should be OK if the number of tests is small and contention is unlikely) or by scheduling such that those tests are never run in parallel.
Requirements wise a question is whether there's a case where we want vendor-specific global state annotations in expectation metadata files. This could be required if a certain browser has implementation-specific global state (e.g. a case where using the media stack from multiple processes at once causes issues).
The text was updated successfully, but these errors were encountered:
Originally filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1866605
In that example we have two tests that use the clipboard. When run in parallel the tests both writing to and reading from the clipboard have an obvious race condition which causes intermittent failures. Our usual approach of partitioning the state doesn't work here because it's OS-level global state; partitioning would be equivalent to requiring tests to be run single-process-per-OS-instance.
To solve this the obvious abstract requirement is some way to annotate which tests are known to require the same shared state. For example:
<meta name=state content=clipboard>
Functionally it would then be up to the runner to ensure that multiple tests declaring the same state requirements don't run in parallel. This could be achieved by each type of state being associated with a mutex that must be acquired before starting the test (should be OK if the number of tests is small and contention is unlikely) or by scheduling such that those tests are never run in parallel.
Requirements wise a question is whether there's a case where we want vendor-specific global state annotations in expectation metadata files. This could be required if a certain browser has implementation-specific global state (e.g. a case where using the media stack from multiple processes at once causes issues).
The text was updated successfully, but these errors were encountered: