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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
