Re: EOFault / NSAutoreleasePool

[David Ayers]

Richard Frith-Macdonald schrieb:
> 
> A thought ...
> 
> Perhaps what NSAutoreleasePool should be doing is calling the runtime
> method (get_imp()) directly ... this will return a pointer to EOFault's
> implementation of -release, or a pointer to the forwarding code if
> EOFault does not implement -release.
> It also has the advantage of being faster than calling
> -methodForSelector: or +instanceMethodForSelector:
> It should also effectively be what would happen if we just called
> -release on the object directly, so it's hard to see how it could be wrong.
> 
> Comments?

I like this because it allows us to remove the
+instanceMethodForSelector: implementation for EOFault making it harder
for people to shoot themselves in the foot.

I don't thing it is more or less wrong wrt calling the "correct"
implementation.  But be aware that for IMP caching in general, the fault
can fire/object be faulted during an iteration making the cached IMP
(whether EOFault's or the forwarding method) invalid for the current
state of the object.

This /can/ happen for NSAutoreleasePool's cached -release message also
but will only have any adverse effect if there are to many autoreleases
(double release bug), since the fault (partially) fires when the retain
count drops to 0 to insure the original classes -dealloc is invoked.
(But in that case the fault's data isn't fetched).

Yet subsequent invocations of the method cached by either get_imp (or
+instanceMethodForSelector: as is done currently) by NSAutoreleasePool
will corrupt the ivars and leave the retain count unchanged due to
double autorelease bugs.

I'm not really worried about it, OTOH I believe it was this kind of
memory debugging that led to the patch in the first place so it may be
important after all...

Cheers,
David