On Thu, 3 May 2001, Artur Bergman wrote:
> does :shared work in bleadperl? attrs.pm doesn't seem to have a clue about
> it? There are two issues here as I see it.
the shared attribute works in bleedperl, but it does not mean what you
think it means. search the archives for GvSHARED, in particular:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-02/msg00535.html
in a nutshell, GvSHARED GVs are not copied across perl_clone, and
piggyback the existing SvREADONLY checks for memory
savings. these `shared' GVs cannot be written to once marked as GvSHARED.
> The first passing a SV between two threads, if the thread that allocated the
> SV destructs it will free the arena that the SV used, (assuming
> perl_destruct_level > 0). I solved this temporarily by creating an empy
> PerlInterpreter for keeping shared variables in.
>
> The second problem is that perl_clone will clone all SVs it can find when
> cloning. (No big surprise). Which means sharing has to implmeneted by either
> magic or tie, both have performance problems.
>
> I assume that :shared would have to set a flag on a SV so it is created
> somewhere off the arena (?) and perl_clone will have to ignore cloning that
> SV (?). Is this something that could go into 5.8? If so I can attempt a
> patch but I am not sure I have the knowledge needed to make those parts
> work.
sharing SVs between interpreters that can be written to is much more
difficult problem. i believe dick hardt coined the term 'solar variable'
for this concept. solar is global variable that is visible to all
interpreters.
i have fiddled with 'our $foo : solar;' using tie (sv_magic). with a
structure along the lines of:
typedef struct {
perl_mutex lock;
SV *var;
} solar_t;
tie like so:
static void solar_scalar_tie(pTHX_ SV *rv)
{
SV *sv = (SV*)SvRV(rv);
SV *obj = newSV(0);
sv_setref_pv(obj, "solar::scalar", (void*)solar_new(aTHX));
sv_magic(sv, obj, 'q', Nullch, 0);
}
when $foo is copied by perl_clone() it gets a pointer (not copied) to
the solar_t returned by solar_new. FETCH and STORE then use the
solar_t.lock to serialize access to the solar variable. what i have works
ok for simple scalars, but dealing with complex structures is, well,
complex. each value of a hash and array would need to be tied, if those
values are hashes or arrays, their values need to be tied, and so on.
so yes, there are performance problems. i have not investigated howto
implement solar variables in the core. however, that approach would need
to take special care not to add overhead to the core for all things
non-solar.
