[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
|