A small number of the tests in LayoutTests/storage/ call window.layoutTestController.clearAllDatabases(). This function deletes all databases in the current profile. This is a good idea; the theory is that tests get a clean slate from which to start. Ideally all database tests would call it before doing anything, so as to avoid any quota problems from leftover databases. However, this is a terrible thing to do if you might be running in parallel with other database tests; you can interfere with any other test that's trying to create or use a database. We're going to need a way to mark these tests as non-parallelizable in order to be able to run them safely under new-run-webkit-tests.
(In reply to comment #0) > A small number of the tests in LayoutTests/storage/ call window.layoutTestController.clearAllDatabases(). This function deletes all databases in the current profile. > > However, this is a terrible thing to do if you might be running in parallel with other database tests; you can interfere with any other test that's trying to create or use a database. Ideally each instance would be using a different "profile", so clearing the databases (clearing caches, cookies, etc.) from one instance shouldn't affect the others. (If this is not the case, then more than this one sets of tests will have issues.)
Eric, do we still have this issue?
(In reply to comment #2) > Eric, do we still have this issue? I've heard nothing that indicates that we don't, so I assume that this is still the case. I haven't looked at the database tests in ages, though. It wouldn't surprise me if a number of the storage tests [IDB, filesystem] have similar issues. I haven't heard any screaming test failures, though--are we not yet parallelized?
We currently shard tests per-directory, so this feature is only needed if we were to move to a more extreme parallelism solution, right?
(In reply to comment #3) > It wouldn't surprise me if a number of the storage tests [IDB, filesystem] have similar issues. I haven't heard any screaming test failures, though--are we not yet parallelized? We are, certainly, but as eseidel notes, we shard per-directory so perhaps we don't see the worst of things by default. (In reply to comment #4) > We currently shard tests per-directory, so this feature is only needed if we were to move to a more extreme parallelism solution, right? Correct, like running with -f :).
(In reply to comment #5) > (In reply to comment #3) > > It wouldn't surprise me if a number of the storage tests [IDB, filesystem] have similar issues. I haven't heard any screaming test failures, though--are we not yet parallelized? > > We are, certainly, but as eseidel notes, we shard per-directory so perhaps we don't see the worst of things by default. > > (In reply to comment #4) > > We currently shard tests per-directory, so this feature is only needed if we were to move to a more extreme parallelism solution, right? > > Correct, like running with -f :). OK, then we're fine for now...as long as per-directory doesn't mean that tests directly in fast/filesystem could run at the same time as those in fast/filesystem/workers.
(In reply to comment #6) > OK, then we're fine for now...as long as per-directory doesn't mean that tests directly in fast/filesystem could run at the same time as those in fast/filesystem/workers. No, that is definitely possible. (And may explain some crashes, failures?)
(In reply to comment #7) > (In reply to comment #6) > > OK, then we're fine for now...as long as per-directory doesn't mean that tests directly in fast/filesystem could run at the same time as those in fast/filesystem/workers. > > No, that is definitely possible. (And may explain some crashes, failures?) What if we (in a separate bug) were to change DumpRenderTree to use a per-test storage directory? Would that fix this trouble for storage?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > OK, then we're fine for now...as long as per-directory doesn't mean that tests directly in fast/filesystem could run at the same time as those in fast/filesystem/workers. > > > > No, that is definitely possible. (And may explain some crashes, failures?) > > What if we (in a separate bug) were to change DumpRenderTree to use a per-test storage directory? Would that fix this trouble for storage? If there's a separate storage directory and separate layoutTestController per test, that should do it.