On 09/03/2012 01:52 PM, Eric Wilhelm wrote: > # from Mark Stosberg on Friday 31 August 2012: >> I looked into the App/Prove.pm source code and immediately spotted the >> issue. It hardcodes that all "rules" should run in parallel. Thus, >> there would be no way to specify that something should never be run >> in parallel with anything else. > > Hi Mark, > > See also: 'rules' in the TAP::Harness pod, the source/comment on > TAP::Parser::Scheduler (_set_rules() &c.), and t/scheduler.t.
Thanks for the reply, Eric. I did look in some detail at the related scheduling code as part of preparing the documentation patch I submitted. > There is a disconnect between command-line flags to prove and the data > structure there. I haven't had time to totally grok the scheduler code, > but I think you need something different than what the --rules option > was written to do (though we would have to ask someone who is using it > whether your patch breaks that use case -- I think the usage was to > prevent just a few tests from running at the same time as each other, > not from all others.) > > In your case, it might be better to be able to just pass a schedule of > nested arrays (maybe as json or something?) At this point, I have confirmed that the right schedule is being generated and used. However, it is triggering a bug elsewhere, perhaps in the aggregation or multiplexing code. At the end of the run, there is simply no summary report generated. However, I may not pursue this further soon at this point because of a course change. It's been so slow to get proper support for exceptions to parallel test runs, that I decided to dig into the problematic tests to see if I could make them parallel friendly. It turns out that was faster just to fix the tests. :) Mark
