Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We need the ability to layer PMCs. Nothing new, we need something of
> the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
* PMCs that have read-only variants have the C<const_too> flag set
* the PMC compiler creates a second set of vtables with all mutating
vtable slots set to functions that throw exceptions
* P0 = new Const<pmc_name> creates a PMC in the constant PMCs header pool
* but the vtable is the plain one first
* so initialization code can set PMC's contents
* setting the "_ro" property to 1 finally switches in the constant
vtable
This scheme is basically working. I didn't look, if MMD changes did
break it, though. It's implemented for the SArray PMC for testing.
There are some unimplemented things WRT constant "containers". The
problem is that all items that a constant PMC refers to, have to be
constant too. That's the same problem as with thread-safe, shared PMCs.
I.e. setting the container as read-only is exactly the same operation as
setting a PMC as shared: it has to cover all contained items too.
E.g. Sub PMCs where constructed as constant PMCs for some time. But
setting properties on such a constant Sub PMC causes DOD errors, because
the property hash isn't constructed with constant buffers yet.
We could of course construct constant PMCs in the non-constant PMCs
header pool too, but having long-lived constant items in a separate header
pool would speed up DOD a bit, because these header pools aren't scanned
for dead objects.
Finally user code could have short-lived read-only PMCs too, which would
need construction in the plain PMC header pool.
leo
[1] classes/sarray.{c,pmc}
t/pmc/sarray.t
