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

Reply via email to