Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41E2FE94.70908@stason.org>
Date: Mon, 10 Jan 2005 17:15:48 -0500
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Gisle Aas <gisle@ActiveState.com>
Cc: perl5-porters@perl.org, mod_perl Dev <dev@perl.apache.org>
Subject: Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
References: <lris6cxgt9.fsf@caliper.activestate.com>
	<41DDA584.1060109@stason.org>
 <41E2C05F.40002@stason.org>	<lrk6qlxior.fsf@caliper.activestate.com>
 <41E2E222.4070202@stason.org> <lr8y71x7yt.fsf@caliper.activestate.com>
In-Reply-To: <lr8y71x7yt.fsf@caliper.activestate.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Gisle Aas wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
>>Gisle Aas wrote:
>>
>>>Stas Bekman <stas@stason.org> writes:
>>>
>>>
>>>>I've played with it some more. The following program demonstrates some
>>>>So again perl doesn't provide enough public API to properly juggle
>>>>perl interpreters.
>>>
>>>I disagree.  The API seems fine to me.
>>
>>No.
>>
>>1) There is a bug in perl_alloc. As my program (see my previous post
>>in this thread) demostrates, perl_alloc will not allocate a private
>>key for a new interpreter (which is proper for perl_clone'd perls, but
>>broken for a different perl running in the same interpreter.
>>
>>2) PERL_SET_CONTEXT has a problem with using the PL_thr_key key, which
>>may belong to a totally different interpreter.
> 
> 
> The design is that there is only one PL_thr_key shared between all
> interpreters.  This is enough as each thread can only execute in the
> context of one interpreter at a time.  The PL_curintep is only used to
> as a flag to indicate if the one PL_thr_key has already been allocated
> or not, as well as remember the "initial parent interpreter under
> useithreads".

Under mod_perl2 you can have independent pools of interpreters, in which 
case I doubt you can reuse PL_thr_key, because those interpreters aren't 
related. Isn't that a problem if two unrelated interpeters try to use the 
same key, sounds like a *very* bad idea under threads. We have enough 
mysterious crashes under threads, I won't be surprised that this is one of 
the reasons. I need to write more tests to tell for sure.

Moreover if perl does get fixed, this modperl2 case is certainly going to 
crash, since it'll destroy the key but other parent interpreters sharing 
it will be still running. My test program demonstrates that quite clearly.

> As I said in an earlier message, using PL_curintep as a flag makes
> perl_alloc() slightly thread-un-safe, but if you just make sure to
> allocate a perl in the parent thread first things should be ok.

it doesn't work when you have more than one parent perl interpreter. 
Moreover PL_curintep is set as soon as at least one parent perl is 
started. So you will delete those more than once.

>>And in any case I didn't see perl fixed and it's not quite clear
>>whether it's going to be fixed at all.
> 
> 
> That's true.  Well, at least ActivePerl is fixed then.
> 
> :)

That's nice :)

Unfortunately that doesn't help the general case.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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