hi, There is an on-going work on run-test (which began as part of last year GSoC). I would begin there instead of working on the current run-test.php. Parallel testing is part of the new features as well, in a portable way (like not only where pcntl is available).
Thanks for your work, Cheers, -- Pierre On Mon, Feb 22, 2010 at 2:11 AM, Raphael Geissert <geiss...@php.net> wrote: > Hi, > > I've spent the last hours working on making run-tests.php be able to run > tests in parallel. The main reason being the time it takes to run the whole > testsuite even on multicore CPUs. > > Attached is the first set of changes needed. It uses pcntl's fork and > sysvmsg to send some of the results back to the parent process. > > Main functionalities still work, but the summary doesn't include failed > tests. > > I plan to move away from sysvmsg because with the current implementation > killing the parent process can leave message queues open (nothing that can't > be fixed by adding a proper exit handler) and sysvmsg is not enabled by > default. Probably to something php://memory-based. > > To support all the features under multi-jobs mode I think the proper fix is > to cleanup the code so that run_test() stores the state information via an > interface. This would make the code cleaner and would let multi-jobs mode > just change the state-storing interface. > > How should I handle this? just by committing the changes? first sending them > here (to internals)? by contacting somebody else? > > Cheers, > -- > Raphael Geissert > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php