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 | | a...@vnl.com "Data Systems for Deep Space and Time" | +---------------------------------------------------------------+ _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
