Re: EOFault / NSAutoreleasePool

[Richard Frith-Macdonald]

On 13 Mar 2008, at 17:03, David Ayers wrote:

> 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.

Yes, though ideally it could work ... because [NSDistantObject- 
methodForSelector:] could return the address of code which will  
forward the message to the other process.  This would actually not be  
too hard to implement.

I'm not to clear on what an NSDistantObject ought to do according to  
the documentation though:
The documentation doesn't say it implements -methodForSelector: or  
+instanceMethodForSelector: so perhaps it should return the address of  
the method in the remote process ... which is kind of odd.  If you  
accept that interpretation then the common practice of caching method  
implementations for optimisation must always be considered unsafe  
unless you can guarantee that no proxy object will ever reach that code.

So ... technically the optimisation in NSAutoreleasePool is clearly  
unsafe, but in practice it's probably worth keeping it even so (the  
person who suggested it to me said it had made a 20% performance boost  
to their code).