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