Re[2]: [GDL2] NSAutoreleasePool/EOFault

[Manuel Guesdon]

On Mon, 14 Mar 2005 20:07:14 +0100 David Ayers <address@hidden> wrote:

 >| Manuel Guesdon wrote:
 >| 
 >| > 
 >| > Another idea is to return NULL in (instance)methodForSelector: to tell 
 >the 
 >| > caller should not use imp or cache the method.
 >| > It should be clean and safe isn't it ?
 >| > The drawback is that callers should verify returned IMP and handle the 
 >| > case...
 >| > 
 >| 
 >| I'm not sure which is worse here.  I think most developers may check 
 >| with respondsToSelector: before caching the IMP but I doubt that they 
 >| would then again check (instance)methodForSelector:.  And even if they 
 >| did and tested all this against non-faulted object, the object can be 
 >| faulted again by virtue of some indirect invalidation notification. 
 >| EO(Fault)s and implementation casting simply don't work well together.

Good point :-(


 >| I've been trying to find some time to think about this.  But I don't 
 >| think we can automagically deal with both optimizations.  Both have 
 >| their merit but the just don't work well together.  We need to support 
 >| EOFaults by design in GDL2.  And we should take care that we design any 
 >| IMP caching optimization as EOFault tolerant as we can.  But I don't 
 >| think that we should skip optimizations if we can insure them to be safe.

Agree.


 >| In the case of the NSAutoreleasePool, I think we are clear as each 
 >| object is tested via GSObjCClass before the release is sent.  The fault 
 >| will be cleared as soon as it is dealloced.  This may trigger other 
 >| faults to fire, but then GSObjCClass will return the real class if those 
 >| faults also still happen to be in the autorelease pool.
 >| 
 >| I've only done some preliminary testing but it seems that EOF's EOFault 
 >| does not implement the class method's and that sending 
 >| methodForSelector: fires a fault.  So EOF will also break with this scheme.

Yes :-(

 >| 

 >| I agree with Richard, that this is all a bit worry some.  But by design 
 >| those two optimization simply don't work to well together.  I think we 
 >| could implement the EOFault class method instanceMethodForSelector: to 
 >| accommodate the NSAutoreleasePool optimization, at least temporarily to 
 >| unbreak GDL2.  

I agree.

 >| Maybe add an NSWarnLog saying. @"Returning an EOFault 
 >| instance implementation pointer for selector:".

OK for a one time warning.


 >| I'm still a bit unsure on how to deal with the methodForSelector: class 
 >| method.  But that's just because it looks like the issue seems unsolvable.

Yes, it's not a simple probleme and I'm too not sure that there's a perfect 
solution.

Another idea is to have a list of class to exclude in a as simple (fast) as we 
can structure (like a c array) to store small number of class to exclude 
from optimization but it will be non sttandard and slower.

Another one could be to not use the EOFault class directly but an EOFault 
derived dynamically created class for each kind of EOFault possible 
class so the class returned by GSObjCClass will 'know' what it is and 
could handle messages better (i.e. its release method can call EOFault -release 
if object is really a fault of real class -release if object is not a fault) 
but it 
introduce a kind of proxy which will be slower...

Just ideas to discuss about :-)

Manuel

--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998