[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
<[EMAIL PROTECTED]>:
> If you have the double-indirect, the window of vulnerability is smaller,
> but it's still there if you're running multithreaded.
Looks zero-sized to me. One memory write, let the garbage collector
collect the old vtable.
Well OK, you need to synchronize between different threads trying to
update the vtable at the same time, but that's a different thing from
synchronising with people just *using* the vtable.
> Unfortunately that
> double-indirection's not going to be cheap, and I don't see that it buys us
> all that much. Yes, it means that updating vtables costs less and is less
> dangerous, but it still costs and isn't free.
So?
Objective-C uses name lookup for method calls and is still plenty fast
enough. (See libobjc in the gcc source tree or from www.gnustep.org.)
That's a *lot* more expensive than double indirection! (And it allows for
runtime changing what methods your class understands, by dynamically
loading libraries [called bundles].)
> Also you have the issue of needing *all* the vtables in the system resized
> essentially atomically. (Or done at least before any code that uses the
> resized vtable to execute, which is more doable) The vtables need to stay
> consistent--if we add a method to one of 'em, we need to add it to all of
> them.
Hmm. Maybe you really should look at the Objective-C way of doing things.
It doesn't need large sparse function pointer tables.
MfG Kai
