[ENH] ContextCleanup-ajh ( [cd][er][et][su] extremely useful; unclear about ContextTag )

Daniel Vainsencher danielv at netvision.net.il
Fri Jun 27 16:55:45 UTC 2003


A. I think we could live with packages that clash over the slot, for
now, because this is so easy to solve in the future (integrate the
packages or create a ContextExtension package as a prereq, so forth).
B. I also think we could live with a ContextExtension now, though it
would break the other packages until they adjust to use it.
C. I even think we can live with the slot being captured now, and have
3.7alpha feature an unfix that uncaptures the slot.

But what I'm sure of is that I don't want this to prevent the cleanups
from entering 3.6. I strongly believe that debugging into all kinds of
guarded blocks should work :-). Everything else we're talking about is
very esoteric compared to that. 

Just my two agorot.

If I understand correctly, the only other issue is with changes to
classes that have been since removed from the image. Andreas, assuming
you've already identified these, can you post a separated version?

Daniel

Anthony Hannan <ajhannan at yahoo.com> wrote:
> Avi Bryant <avi at beta4.com> wrote:
> > 
> > On Thu, 26 Jun 2003, Anthony Hannan wrote:
> > 
> > > But I would still like to have working stack copies in conjunction with
> > > possible other experiments like delegation.  What if we used receiverMap
> > > to hold a record containing the ContextTag and other slots as desired
> > > for delegation, JIT, etc.  Then we can have all at once instead of
> > > choosing.  The record would only be created on demand (contextTags are
> > > only needed for signal contexts and block closure homes).  And the extra
> > > indirection is still pretty cheap.  What do you think?
> > 
> > What was wrong with Andreas' suggestion that ContextTag be a package that
> > could be loaded by those that need correct stack copying, but not part of
> > the base enhancements?
> 
> Then you could never load more than one enhancement that uses the receiverMap
> at the same time.  Adding a ContextExtension record allows us to load as many
> as we want (or for a single enhancement to utilize more than one slot).
> 
> >  Since AFAIK the only current user of Continuation
> > is Seaside, and it can make do without ContextTag, it seems unfortunate to
> > restrict ourselves or take a performance hit (and isn't BlockContext>>home
> > used quite frequently?) for a total of 0 users.
> 
> I don't think there is a performance hit.  Returning to a block home also
> involves checking for ensure:/ifCurtailed: contexts in between so I don't think
> the extra indirection will be significant in comparison.  Also returning blocks
> are actually quite infrequent.
> 
> > I very much appreciate the desire to make as much as possible work
> > correctly out of the box, but - you've done the work on ContextTag and we
> > know it's there if we need it, now let's find a reason to need it.  Until
> > then, it doesn't make sense to me to give up the receiverMap slot or
> > introduce any extra indirections.
> 
> All right, I just thought of another idea.  Since only particular contexts
> (block homes, signal contexts, and #on:do: contexts) are referenced by a
> contextTag, I can compile these specially so the contextTag is held in the
> first temp instead of the receiverMap.  To make sure it is not some other
> context that happened to store a random contextTag in its first slot, the
> method will have to be marked as well.  But since we are out of header bits,
> the code itself will be the marker.  Only contexts with contextTags will start
> with the following code: pushThisContext, send: #contextTag, storePop: 0.
> 
> Cheers,
> Anthony
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com



More information about the Squeak-dev mailing list