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: Thu, 17 Mar 2005 14:56:06 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

Manuel Guesdon wrote:

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

Please commit you fix for now.


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

OK for a one time warning.

Fine, but I think the GSOnceFLog/GSOnceMLog macros are not part of -baseadd yet.

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

The problem is, that you can't always identify the class. If you have an unfaulted custom class you don't know whether it will ever be faulted. And whether you want the fault's implementation or the objects implementation depends on the context. For NSAutoreleasePool's release we're just lucky.

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

You mean verifying in the -release implementation of EOFault that the receiver is still a fault... and if not actually sending [self release]... And a custom object's release implementation (well actually our (GDL2's) -release implementation of NSObject) would have to check whether we are actually a fault currently, and if so, send [self release]... hmmm maybe it could work as long as no one overrides release. But it it quite a hack and it would be applicable to retain and a few other methods also. I'll spend some more time thinking about it.

Cheers,
David





reply via email to

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