https://bugs.winehq.org/show_bug.cgi?id=20987
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED CC| |fgouget@codeweavers.com
--- Comment #4 from François Gouget fgouget@codeweavers.com --- While supporting parallel runs might work for some tests, there are many tests that will conflict with each other: * The DirectX tests that change the screen resolution will conflict with all other GUI tests. * So will user32:sysparams because it changes the size of fonts, borders, etc. * Two sound capture capture tests cannot run at the same time (e.g. winmm:capture and mmdevapi:capture). * Even sound playback tests risk interfering with each other. * Clipboard tests will definitely interfere with each other (only one process can call OpenClipboard() at a time). This will also break user32:edit which contains some clipboard interactions. etc.
Keeping track of which tests can be run in parallel and which must be run in isolation is going to be a nightmare. So I think we don't want to fix this.
Note: As far as continuous integration platforms (such as the TestBot) are concerned, the solution to this is to run as many VMs in parallel as necessary to achieve the desired throughput. This requires more (Windows) licenses, and virtualisation software that really shields VMs from each other performance-wise. Also this does not help if the goal is to get the result of a specific WineTest run faster. But it's probably the only sane way.