Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Layering PMCs
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Dan Sugalski  
View profile  
 More options May 29 2004, 3:29 pm
Newsgroups: perl.perl6.internals
From: d...@sidhe.org (Dan Sugalski)
Date: Sat, 29 May 2004 15:29:42 -0400
Local: Sat, May 29 2004 3:29 pm
Subject: Layering PMCs
Okay, time to think about this.

We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
(though we don't have to do it that way) and folks are going to want
to do undoable custom vtable layering. While we don't *have* to let
'em do that, I'm inclined to if only because a good general-purpose
mechanism will make things less error-prone overall.

So, then, the question is... how? I've got two schemes, neither of
which I completely like, so I'm up for some discussion and more ideas.

The first scheme is with simple layered PMCs. You throw a read-only
layer on a PMC and we allocate a new PMC where all the write vtable
entries throw an exception and all the other vtable entries delegate
to the PMC in the next layer below, and we hang that PMC off our
read-only PMC's data pointer.

The second scheme is somewhat more complex. When we mark a PMC as
read-only we allocate a new PMC, copy the contents of the current PMC
to the new PMC, and rejig the internals of the current PMC to have
the read-only vtable. Again, write entries throw an exception, reads
get delegated to the original PMC which is hanging off the data
pointer.

The problem with the first scheme is that anything that has a handle
on the PMC will not get the new layers. Not a good thing.

The problem with the second scheme is that anything that peeks at the
internals of the PMC (like the ultimately wrapped PMC) will either
look at the wrong internals (if it vectors off the PMC pointer) or
will need an extra layer of indirection to get at the internals,
since we'll need to walk down through potentially several layers to
get to the ultimate real PMC.

We could do some sort of merged vtable thing, but besides being
somewhat memory expensive (as we need a new table for each layered
PMC) it also makes it tough to delegate to an inner layer's vtable
function that you've overridden, so that's not good either.

I'm up for opinions or other suggestions.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.