Re: EOFault / NSAutoreleasePool

[David Ayers]

Fred Kiefer schrieb:

> I only follow this discussion with out any deeper knowledge of the
> subject, so my suggestion may be utter nonsense. But to me it seems that
> NSAutoreleasePool does the right thing. It seems wrong to me to return a
> different selector from +instanceMethodForSelector: than from
> -methodForSelector:.

If one would call:

[[aFaultedObject class] instanceMethodForSelector:@selector(release)];

one would actually get the implementation of the unfaulted object.

Yet if one would call that method directly on the faulted object, you'd
get undefined behavior (ie most likely some kind of memory corruption if
ivars are being accessed before some other method happens to fire the
fault).

But what NSAutoreleasePool was doing is:
[GSObjCClass(aFaultedObject) instanceMethodForSelector:@selector(release)];

When this optimization was introduced I had to add the implementation to
EOFault even though it shouldn't be needed.  But since most other code
never saw the EOFault class (as they call -class instead of
GSObjCClass()), didn't use +instanceMethodForSelecotor: but called
methods which would trigger forwardInvocation: (just like
methodForSelector: does) that didn't much matter.

> Why cannot both methods on EOFault check whether is
> is save to return the method from the un-faulted class and only then
> return this method otherwise fault and return the method from the new
> class.

The EOFault class method +instanceMethodForSelector: has no access to
the instance whos class was obtained by GSObjCClass().  It therefor
cannot have access to the actual class of the fault and therefor it's
methods.  But even if it did, invoking those methods directly (i.e.
bypassing forwardInvocation:) will break the code.

> This is clean and will work with any version of GNUstep base or
> any other clean implementation of Foundation. What EOFault currently
> does is rely on implementation details and this is usually asking for
> trouble.

NAK :-) Try to compare EOFault to an NSDistantObject.  Attempting to
cache the implementation pointer of a method in a different process and
bypassing forwardInvocation: will not work.

Cheers,
David