Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100853
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error)
Message-ID: <1507644254.2615.12.camel@schlueters.de>
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
Date: Tue, 10 Oct 2017 16:04:14 +0200
In-Reply-To: <3F.F6.49033.4AEBCD95@pb1.pair.com>
References: <1B.6B.16800.8BF99D95@pb1.pair.com>
	 <1507637348.2615.4.camel@schlueters.de> <3F.F6.49033.4AEBCD95@pb1.pair.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Parallelised run-tests.php (patch)
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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