perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gisle Aas <gi...@ActiveState.com>
Subject Re: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
Date Mon, 10 Jan 2005 21:58:02 GMT
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".

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.

> 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.

:)

Regards,
Gisle

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


Mime
View raw message