perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Ing-Simmons <n...@ing-simmons.net>
Subject RE: [PATCH] libperl leaks a THREAD_KEY each time it is reloaded
Date Tue, 11 Jan 2005 19:26:59 GMT
Jan Dubois <jand@ActiveState.com> writes:
>On Tue, 11 Jan 2005, Nick Ing-Simmons wrote:
>> Gisle Aas <gisle@ActiveState.com> writes:
>>>
>>> The thread key is not property of an interpreter. It is a single
>>> global shared between all the threads running in the process space.
>>> Same goes for PL_curinterp, it's a true global. The concept of having
>>> different interpeters use different thread keys does not make sense.
>>
>> It _could_ make sense. You could have an one interpreter per thread
>> with OS key for thread-local data accessed via the thread_key. In such
>> a scheme variable should obviously not be a true global but an
>> intepreter one.
>
>I don't understand this.  The thread key is used to *find* the current
>interpreter by those function that don't get passed the Perl context
>for backward compatibility reasons.  If you already knew the context,
>then you wouldn't need the whole thread local storage thing in the
>first place.

Whoops, I see what you mean. I forgot what we were getting from where.
So in the "pool" case it makes sense to associate the context with the 
thread in the pool table and save the lookup.

So Gisle us correct - the thread _key_ is a true global,
it is the value stored under that key in each thread which is unique 
to each thread - that being the interpreter pointer associated with 
the thread. Got it.



>
>Cheers,
>-Jan 


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


Mime
View raw message