discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep and valgrind


From: Fred Kiefer
Subject: Re: GNUstep and valgrind
Date: Fri, 16 Mar 2018 09:51:23 +0100

Hi Anon,

I don’t want to stop you in your plans to subclass/rewrite NSAutoReleasePool if 
you think you have to do this, just go ahead. But there are other less 
problematic ways to achieve the same results.

1) David would probably point you to the usage of ARC but as far as I 
understand you are using gcc and this is no option for your.

2) In Objective C it is a popular concept to use intermediate auto release 
pools. That is if you have a bit of code that creates a huge amount of short 
lived objects, wrap that code in its own auto release pool and most of this 
objects will be gone when the pool gets cleaned up. This technic gets used a 
lot in loops where each iteration may have its own auto release pool. This is 
how the gui code handles events, each event processing is included in its own 
auto release pool. Even if you application has no gui, there will be some sort 
of main loop and you could use this technic there.

3) In most cases you don’t have to use the class methods to create objects. 
They are mostly short cuts to make live easier. In many cases there are similar 
init methods that take the same arguments. So instead of [NSString 
stringWithFormat: XXXX] you could be using [[NSString alloc] initWithFormat: 
XXXX] this is more clumsy but gives you full control over the live time of your 
object.
 
Hope this helps,
Fred

PS: Did you ever give a try to the memory diagnosis function I pointed you to 
in my previous mail? This is not gui specific it is implemented on the base 
level. Gui just offers a simple way to view this information.


> Am 16.03.2018 um 01:07 schrieb amon <address@hidden>:
> 
> I've been continuing my slog up the learning curve of valgrind
> and the like. I've also found the tool I wrote to be quite useful.
> 
> At this point I am seeing one key issue behind much of my
> storage issues. It's the autorelease pool. I'm in an environment
> where pretty much anything that goes into it might as well be
> a leak, because there is never a release. Systems are intended
> to run for days, months, years and that means I've got all sorts
> of crud vanishing into the pool that I have no control over.
> 
> In many cases there seems to be no choice but to use the methods
> that return autoreleased storage because there is no instance
> method varient of them. This is particularly the case in NSString
> where all the useful string initializers are Class methods only.
> So I'm between a rock and a hard place there.
> 
> And please, if you haven't been in this discussion with me
> before, note that I am working on embedded real time systems.
> There is no GUI. There is no event loop where everything can
> be released each iteration. It just sits there and does what
> it has been commanded to do and listens over links to parent
> and child hosts/processes forever. I have to control the
> allocations pretty much manually with retain's and releases.
> 
> I can think of some hacks though... what if there were a pool
> drain method that did not decrement the retain count unless
> it was one already? Or if there were a method that let you
> remove an object from the pool? Seems like it would be at least
> possible to subclass NSAutoreleasePool and add such behavior.
> After all, that's why the CS Gods gave us OO!
> 
> -- 
> +---------------------------------------------------------------+
> |   Dale Amon                  Immortal Data                    |
> |   CEO             Midland International Air and Space Port    |
> | address@hidden       "Data Systems for Deep Space and Time"     |
> +---------------------------------------------------------------+
> 
> _______________________________________________
> Discuss-gnustep mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep




reply via email to

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