On Thu, 3 May 2001, Gurusamy Sarathy wrote:
> The way I see :shared working is this:
>
> * :shared declares a normal SV that has a new type of magic
> * the SV is a front-end for access to some shared data (could be a
> region of memory that's created on first access, or could be
> a SV from a global pool)
> * all the magic callbacks for this new magic type will have
> locks to control access (reads don't lock unless a write
> is in progress)
> * shared SVs are cloned just as any normal SV by perl_clone()
Are you saying that you see the locking happening transparently from
user-code? Ie.,
our $sv : shared = "foo";
# Start some threads here, then...
print $sv; # read-only, no lock according to above?
$sv = "bar"; # locks $sv for read/write
Would this not litter the core with lots of tests for sharedness and
subsequent SvLOCKing? Also, it would seem to be prone to race conditions
or deadlock unless the relevant operations could be made atomic.
If so, I would think it better to put the onus on the programmer to guard
entry to such critical sections, rather than trying to do it
transparently.
Cheers,
-Ben
--
signer: can't create ~/.sig: Network is down
