gnustep-dev
[Top][All Lists]
Advanced

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

Re: [GDL2] NSAutoreleasePool/EOFault


From: David Ayers
Subject: Re: [GDL2] NSAutoreleasePool/EOFault
Date: Sat, 12 Mar 2005 20:02:48 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

David Ayers wrote:

Manuel Guesdon wrote:

+ (IMP) instanceMethodForSelector: (SEL)aSelector
{
 if (aSelector == 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, aSelector);
}

[snip]

I guess all methods which currently wouldn't fire the fault, could return EOFault's implementation (like release) and the others should return the fault handler's targetClass implementation... but if EOFault's implementation is used directly on the object after the fault fired, or the object's implementation was cached and is later used on the faulted object things get really nasty... So:

A) it depends on the selector whether we want the fault's implementation or the targetClass of the fault handler... B) it depends on how long the returned implementation pointer is valid. (i.e. when the fault is fired or an object is faulted)

I think the problem is caching implementation pointers of "volatile" objects like this. OTOH, I don't really want to loose Richards optimization as it's pretty useful in the general case. But this may be a show stopper.

I'm also unsure what to do with EOFault's instanceMethodForSelector: in general as this cannot really be used reliably but it's just as unreliable as the default instanceMethodForSelector: for objects that mutate like EO's. It would seem "safe enough" if one could insure the "stability" of an object for some period, but even in this confined situation the releasing can cause deallocing which will in turn cause the fault to fire it and that may cause objects owned through relationships to dealloc/fire...

I'll have to ponder about this a bit longer... but I think it may be safest to maybe undo the NSAutoreleasePool optimization (at least when GDL2 is present).

Cheers,
David





reply via email to

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