Re: [PATCH 0/4] baby step toward multi-target

[Tom Tromey <tromey at redhat dot com>]

Tom> However, it's probably useful as a starting point for the next attempt
Tom> at multi-target.  In particular it's much less invasive than the earlier
Tom> approach, and the "convert current_target to be a pointer" patch (the
Tom> biggest one) was mostly done with a perl one-liner.

Pedro> Yeah.

Pedro> Hmm, kind of orthogonal, but not really, I wonder how far are we
Pedro> to getting rid of the remaining target stack annoyances.  Like:

Pedro>  #1 - Convert the remaining data fields to methods.  That seems it'll
Pedro>       just be boring work.

Agreed.

Pedro>  #2 - making the debug target a wrapping target around each
Pedro>  target layer (as you suggested elsewhere).  That'll require
Pedro>  make-target-delegates hacking.

And a bit of hacking in the same spots touched by the "identity" patch
in this series.

It doesn't seem very hard.

Pedro> That'd then make it possible to:

Pedro>  #3 - eliminate the squashed current_target, replacing it with a pointer
Pedro>       to the topmost target in the stack (mostly the same as your
Pedro>       perl one-liner).

Pedro> Is that in line with what you've been thinking?  I'm wondering whether
Pedro> you found out in the more invasive branch that it's useful if
Pedro> current_target is more than a struct target_ops pointer ?
Pedro> (or "struct target *" after vtable-ification.)

I think it's reasonable to try to get there.
Certainly at this point the squashed target is not extremely useful.
You can see this by looking at how few uses of INHERIT remain.

This would also let us zap the uses of "current_target.beneath" that we
discussed yesterday.


The more invasive branch took a different approach to target identity.
Rather than the to_identity field, it split target_ops into a const
vtable part and a payload part.  Then it aimed to require all targets to
instantiate a new object.

This obviously has to touch a lot of code.  And, it runs into some
difficulties where the target code must work with uninstantiated
targets.

I don't think this is as much of an issue on the new branch.
At least from what I recall the uninstantiated business isn't a big
issue because this only affects a subset of methods, which can simply
avoid looking at the payload.  Also perhaps the target delegation
changes cleaned things up a bit too, I forget.

On the new branch, having current_target be a pointer is preferable just
because it makes target-swapping cheap -- it just means redirecting two
pointers (it could be one pointer, but I chose to keep current_target a
global, always pointing into the current target_stack object; this means
the target stack can be opaque).

I didn't consider making current_target have some other type.

Tom