Re: Parallelised run-tests.php (patch)

From: Date: Tue, 10 Oct 2017 14:04:14 +0000
Subject: Re: Parallelised run-tests.php (patch)
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-100853@lists.php.net to get a copy of this message
On Di, 2017-10-10 at 13:35 +0100, Andrea Faulds wrote: > > This is cool! I also see (from very very very) short look on the > > github diff that you have a parallelization protection for some > > tests, which  might share resources. Very good! > I'm glad you like it! Although I discover now that I am hardly the > first to attempt this. Hardly, aside from the mentioned one's Zoe once did a rewrite which works parallel, phpUnit also has a phpt mode and I'm sue there are yet others ;-) > Maybe I'll be the first to get it merged :p Keep working to hat goal! We need it. (your marketing missed the gcov run btw. :D) > > > > Kind of unrelated: Somewhere on my 10+ years old todo list I also > > have > > the item of using FastCGI or similar for running tests to avoid > > running > > tthrough MINIT/MSHUTDOWN for each and every test (for some we can'T > > avoid due to ini requirements, but well) maybe a less hackish way > > for > > parallelizing might be using fpm workers and async io (just to spin > > the > > idea, maybe somebody takes it up ...) > That's a reasonable idea. But I wonder if at that point, we should > just use a “real” unit-testing framework, or at least a stripped-down > version of one, which would run functions rather than files. PHPT is > a simple format, but it requires invoking a PHP interpreter every > time. We only really need to do that if we expect a fatal error or > something like that… :) We need a PHP interpreter also for leaks, ini settings (we should actually get rid of most of these ...), everything where we need a clean space to register classes/functions/... or where shutdown behavior is tested or so many else :-)  (and yes, detecting leaks via my fastcgi/fpm approach is not trivial, but might be doable with some help from engine/sapi) PHP has a nice mechanism for providing a clean environment, the RINIT- SHUTDWN-cycle ... aka request :-) Anyways, let's not get distracted and work on the proposal at hand and then do the next iteration (... in ~20 years :-/ or can we speed up?) johannes

« previous php.internals (#100853) next »