Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of torsten.foertsch@gmx.net
 designates 212.227.15.18 as permitted sender)
Message-ID: <543F9A5A.7020200@gmx.net>
Date: Thu, 16 Oct 2014 12:13:46 +0200
From: =?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= <torsten.foertsch@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: =?UTF-8?B?SmFuIEthbHXFvmE=?= <jkaluza@redhat.com>,
 dev@perl.apache.org
Subject: Re: release blockers?
References: <53FDAB06.4060906@redhat.com>	<54130AD0.7090509@redhat.com>
	<20140912151511.GA3767@estella.local.invalid>
 <CADED=K6A1N_pYhSytYHZkQaQBzWTnoQYV_+urpRoLhAUS8Bdng@mail.gmail.com>
 <5417E206.6070308@redhat.com>
In-Reply-To: <5417E206.6070308@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 16/09/14 09:08, Jan Kaluža wrote:
>> Works for me last time I tried, but t/perl/ithreads* are not in the
>> release tarballs anyway, I think (because of persistent trouble with
>> them historically).
> 
> I've tried it with worker MPM and it fails for me, but I think the test
> is somehow broken. The comment in ithreads3.pm says:
> 
>     # now add an extra PerlCleanupHandler. It is run each time the
>     # interp is released. So it is run after Trans, MapToStorage and
>     # Fixup. In the response phase $counter should be 5. After Response
>     # it is run again but that is after.
> 
> But when checking the code for PerlCleanupHandler, it seems to be run
> once the request request_rec.pool is destroyed, which is in
> contradiction with the comment.
> 
> It then continues with:
> 
>     # This used to eat up all interpreters because
>     # modperl_interp_unselect
>     # calls modperl_config_request_cleanup that allocates a new interp
>     # to handle the cleanup.
> 
> This is also not a true in current code. modperl_interp_unselect does
> not call modperl_config_request_cleanup if I understand the current code.
> 
> I would say the test is outdated and I have no clue what was its goal.
> It clearly tries to count how many times are the handlers executed, but
> in its current state, it is not useful, because it tests the code paths
> we no longer have.

Back around 2.0.4 or so, we had several bug regarding interpreter
allocation/deallocation. I especially remember 2. The first one
allocated a separate interpreter for the response phase. So, you got
different interpreters for fixup and response for instance. Then we had
a complete mess with "PerlInterpScope handler". Perhaps the test is for
one of these cases.

We also had a bug that a PerlCleanupHandler was not called at all if
another perl handler hadn't been invoked prior in the request cycle. Not
sure if we have a test for that or if we even have fixed it.

I think all of these bugs should have been eliminated with the change
from simple flag-based interpreter management to refcount-based. I
believe this is what the current code is based upon, right?

Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org