gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOFault / NSAutoreleasePool


From: David Ayers
Subject: Re: EOFault / NSAutoreleasePool
Date: Wed, 12 Mar 2008 17:51:34 +0100
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110)

Helge Hess schrieb:
> On 11.03.2008, at 19:37, David Ayers wrote:
>> if you are using ogo with gdl2... is that the case?
> 
> 
> No, OGo/SOPE uses its own variant of GDL1. But I assume that EOFault
> handling is more or less the same.
> 

Probably not quite :-)

We took percautions due to (the old) NSAutoreleasePool optimization:

/**


 * Returns a pointer to the C function implementing the method used


 * to respond to messages with selector by instances of the receiving


 * class.


 * <br />Raises NSInvalidArgumentException if given a null selector.


 *


 * It's a temporary fix to support NSAutoreleasePool optimization


 */
+ (IMP) instanceMethodForSelector: (SEL)selector
{
  if (selector == 0)
    [NSException raise: NSInvalidArgumentException
                format: @"%@ null selector given",
NSStringFromSelector(_cmd)];
  /*


   *    Since 'self' is an class, get_imp() will get the instance
method.

   */
  return get_imp((Class)self, selector);
}

But now that Richard has committed that "fix" we'd also have to
implement methodForSelector: ...

But actually the above implementation is broken... we should only be
returning the implementation pointer for the selectors that can be
safely invoked without firing the fault.  All other selectors should
fire the fault first and then return the method of the real object.

Of course caching EOFault/EOEnterpriseObject methods is risky business
as the same object may be refaulted/fired do to certain side effects.

For example it would very bad if an EOEnterpriseObject caused other
faults to fire during -dealloc.

Cheers,
David
        




reply via email to

[Prev in Thread] Current Thread [Next in Thread]