develooper Front page | perl.perl5.porters | Postings from May 2002

Re: perl@16433

From:
Gurusamy Sarathy
Date:
May 6, 2002 17:23
Subject:
Re: perl@16433
Message ID:
200205070022.g470MTe17780@smtp3.ActiveState.com
On Mon, 06 May 2002 23:21:47 BST, Nicholas Clark wrote:
>On Mon, May 06, 2002 at 05:50:38PM +0300, Jarkko Hietaniemi wrote:
>> - Storable finishing touches [Nicholas]
>
>As Storable already passes a context object around to make itself thread
>safe,

This "non-standard" context object (really just an old iteration of
the MY_CXT stuff) should be reworked to use the standard MY_CXT macros
that use an SV to allocate their space.

>and the leaking problem is only that the malloc()ed buffers:
>	struct extendable keybuf;	/* for hash key retrieval */
>	struct extendable membuf;	/* for memory store/retrieve operations
> */
>	struct extendable msaved;	/* where potentially valid mbuf is save
>d */
>
>don't get free()ed at thread exit,

I think you missed this:

      Newz(0, cxt, 1, stcxt_t);                              \

>will it work replacing struct extendable
>with an SV? And letting the arena cleanup free the SV at thread exit?

Yes that will work, and the MY_CXT stuff does that for the main context
object.

>I'm not convinced that using the MT_CXT macros in perl.h is actually needed,
>as they are described by this comment
>
> * Boilerplate macros for initializing and accessing interpreter-local
> * data from C.  All statics in extensions should be reworked to use
> * this, if you want to make the extension thread-safe.  See ext/re/re.xs
> * for an example of the use of these macros, and perlxs.pod for more.
>
>which implies that they are intended for reworking extensions that currently
>use static variables.

Maybe it needs to be reworded to say "global" rather than "static"
then?

Thanks,


Sarathy
gsar@ActiveState.com



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About