Re: EOFault / NSAutoreleasePool

[Richard Frith-Macdonald]

On 13 Mar 2008, at 16:32, David Ayers wrote:

> Richard Frith-Macdonald schrieb:
> > Well I could revert the 'fix'.
> >
> > I assumed that it was safer to call -methodForSelector: on an object
> > than -instanceMethodForSelector: on a class, since any  
> > implementation of
> > the former would have more information to work with (knowing details
> > about the instance) in cases where the underlaying class was
> > implementing a proxy to some other object.
> > Of course, in an ideal world every class *ought* to have a correct  
> > and
> > reliable implementation of both methods ... I was just trying to go  
> > for
> > the option which I thought most likely to be reliable in practice.
>
> Well there are a few examples of classes on which you cannot not call
> arbitrary methods at arbitrary times.
>
> - NSAutoreleasePool itself raises on retain and autorelease and  
> therefor
> cannot be added to collections.

Yes.

> - It is invalid to call methods that auto release any objects during
> dealloc/release for any object because these methods get called during
> -emptyPool,

No ... or at least I mean, if so I don't understand your reasoning.
Can you say why you think that an object which is being deallocated  
should not autorelease anything?  My belief is that objects being  
deallocated should be free to autorelease things.  Maybe the Apple  
documentation says otherwise somewhere though.

> And firing EOFaults (what actually happened to NSFaults? I remember
> discussing those a once) will do exactly that.  It generally implies
> database access, creating many auto released objects to populate the
> attribute instance variables including accessor methods which all  
> could
> validly call autorelease.

Sure, but as far as I know that's fine.  Anything which is  
autoreleased during emptying of a pool should just get added to the  
end of the pool  and then released later during the emptying. Barring  
bugs of course.

> > > I would want to add another special handling.  EOFaults are indeed  
> > > not
> > > standard ObjC constructs that require special treatment (Probably  
> > > like
> > > NSProxy also).  They try to be transparent objects but there are  
> > > some
> > > rules.  Just like one isn't allowed to send certain methods to
> > > NSAutoreleasePool instances, EOFaults are also special.  I don't  
> > > think
> > > these optimizations should be allowed to have such an impact on the
> > > semantics other features.  I think we had a good compromise with
> > > +instanceMethodForSelector: (but we my still need to improve on that
> > > within GDL2).  But asking us handle -methodForSelector for an
> > > optimization seems to be rather tough.
> >
> > I'm happy to revert the change ... but at the same time I think  
> > EOFault
> > should have properly working implementations of all the basic  
> > methods of
> > NSObject and NSProxy.  However, I have no knowledge of the  
> > complexity of
> > EOFault, so I don't know how much work that would be ...
> >
> > Just let me know what you want me to do.
>
> There are defined methods that do /not/ cause an EOFault to fire and
> they have been carefully selected to cope with Foundation's paradigms.
> They are:
>
> -retain
> -release
> -autorelease
> -retainCount
> -class
> -superclass
> -isKindOfClass:
> -isMemberOfClass
> -conformsToProtocol:
> -isProxy
> -methodSignatureForSelector:
> -respondsToSelector:
> -zone
> -doesNotRecognizeSelector:
>
> These methods also don't fire the fault but they don't "hide" the fact
> that the object has been faulted:
>
> -description
> -descriptionWithLocale:
> -descriptionWithIndent:
> -descriptionWithLocale:indent:
> -eoDescription
> -eoShallowDescription
>
> (see:
> http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Library/Frameworks/EOControl.framework/ObjC_classic/Classes/EOFault.html)
> (http://tinyurl.com/ys3ebu)
>
> everything else should fire the fault.  In particular  
> methodForSelector:
> should fire it so that you will get the implementation of the real  
> class
> and insure that the real class is available.  Yet the side effects of
> firing the fault (which are valid in most contexts) aren't valid for
> -emtpyPool.  (see above)
>
> NSAutoreleasePool is a special class that has semantics that effect
> every Foundation based application / library.  Especially -emptyPool  
> has
> to be careful not to implicitly invoke methods that need an auto  
> release
> pool in place.  And there are other issues it needs to take into  
> account.
>
> For example, if you were to attempt to obtain the class with -class
> instead of GSObjCClass you'd get the target class instead of EOFault.
> Then +instanceMethodForSelector: would give you the implementation of
> the original object, yet you'd be invoking it while it is still  
> faulted.
>
> I would argue that invoking /anything/ but -release (and
> -retainCount/retain if necessary) is likely to be bug.  But I have a
> strong sympathy for the IMP caching when an object has a high retain
> count.  So I'm fine with the GSObjCClass/+instanceMethodForSelector:
> approach even though this is already rather shady.
>
> I really don't think -methodForSelector: should avoid fireing  
> depending
> on the selector.
>
> So, yes I do think the patch needs to reverted.

OK.