gnustep-dev
[Top][All Lists]
Advanced

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

Re: Next GNUstep release?


From: Fred Kiefer
Subject: Re: Next GNUstep release?
Date: Tue, 30 Mar 2010 09:59:17 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3

Am 30.03.2010 08:45, schrieb Wolfgang Lux:
>> Mhm, I already did all of that yesterday...
>>
>> But there is more to do. We now need to change all the places where we
>> load NIB (or Gorm or XIB) files to free the top level objects. The code
>> is a lot cleaner now, but as far as memory leaks are concerned we are
>> almost back to square one. We now leak all the top level objects again
>> :-(
>>
>> I will try to solve this later today, but wouldn't mind if anybody beats
>> me on this before I come back from the cinema.
> 
> Not sure if there is a misunderstanding here. With respect to the
> (usual?) case where applications don't explicitly ask for the top level
> objects, my patch did not change anything. The patch only affected the
> case where applications explicitly ask for the top level objects and in
> that case it ensures that those objects are not released prematurely (at
> least compared to Cocoa). So unless you mixed in some other changes, I
> don't see what you want to fix here.

You are right, this change did not make any difference for the case
where we don't provide an array for the top level objects. It just made
it clearer that in this case we might be leaking these objects.

Just imagine an NSDocument NIB file with plenty of top level objects
that go unhandled. What should we do in this case? Try to be clever in
our own NIB loading code? E.g. provide an array for the top level
objects and free them later on? Most likely this isn't what Cocoa is doing.

For the moment I think it is good enough to ignore the issue until it
shows up to be a real problem.




reply via email to

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