Front page | perl.perl5.porters |
Postings from May 2002
Re: perl@16433
Thread Previous
|
Thread Next
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
Thread Previous
|
Thread Next