On Thu, 3 May 2001, Gurusamy Sarathy wrote:
> On Thu, 03 May 2001 09:48:45 PDT, Doug MacEachern wrote:
> >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,
>
> Or accessed through TIEHASH and TIEARRAY.
right, that's what i meant by 'need to be tied'.
> >their values need to be tied, and so on.
>
> Or ensure that only solar values are stored within them.
if solars are implemented as ties, isn't that the same thing? :)
i think we're on the same page, what i'm saying is consider the code
below, which prints:
STORE: foo => HASH(0x817051c)
FETCH: foo
serialization would be lost here:
$h->{two} = 2;
to solve, STORE would need to make sure the value is already solar tied or
take care to tie it, so that access to references such as $h->{two} are
also serialized. if %$h contains values which are references, they
must also be solar, which means walking the entire value structure
for each STORE. ugh.
then of course there's more problems with certain structures, such as CV,
which cannot share padlists across interpreters without duping the CV or
pp_entersub becoming aware and locking the CV. or something like a DBI
reference who's MAGIC has a pointer to a database connection handle which
cannot be used concurrently in multiple threads.
package Foo;
sub TIEHASH {
bless {};
}
sub FETCH {
my($self, $key) = @_;
print "FETCH: $key\n";
return $self->{$key};
}
sub STORE {
my($self, $key, $val) = @_;
print "STORE: $key => $val\n";
$self->{$key} = $val;
}
tie %hash, 'Foo';
$hash{foo} = {one => 1};
my $h = $hash{foo};
$h->{two} = 2;
