• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: nested autorelease pools?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nested autorelease pools?


  • Subject: Re: nested autorelease pools?
  • From: John Stiles <email@hidden>
  • Date: Tue, 1 Nov 2005 14:13:12 -0800

On Nov 1, 2005, at 1:56 PM, j o a r wrote:


On 1 nov 2005, at 22.36, John Stiles wrote:

I'm no expert here, but I suspect if we have a simple NSThread that's used for one purpose, we can create an NSAutoreleasePool as it's initialized and release the autorelease pool as the thread is dealloced, and everything will work. I can't see how that could be a problem.

As threads in general have one entry point, and one exit point, I'm also not sure what the point of that non-standard, rule-breaking, exercise would be? The simple pattern of bracketing the method you run with your thread works well for this, don't you agree?

Can't disagree.

I think the real reasons behind this warning in the documentation are stacked NSAutoreleasePools.

Yes, and the current autorelease pool is found by walking up the stack.

Well, the more common phrasing is "the top of the stack," but I know what you mean. (Walking usually implies pointer chasing of some sort, like walking a linked list.)


Perhaps autorelease pools shouldn't be objects at all, but rather some sort of ObjC language construct? Something similar to the new syntax for exception handling:

@AutoreleasePool
{
	// Stuff
}

And if you're in a tight loop and need to drain the pool every now and then:

@AutoreleasePool
{

	if (SomeCondition)
	{
		@DrainPool
	}
}

I'm not exactly sure what the benefit here is, other than an enforced release of the pool. If that's what you want, just use Objective-C++ and create a C++ class. Its constructor can create the pool, and you can make a method to drain your autorelease pool. When it goes out of scope, the destructor can release the pool. Taking advantage of scoped object lifetimes is a C++ specialty.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Follow-Ups:
    • Re: nested autorelease pools?
      • From: j o a r <email@hidden>
    • Re: nested autorelease pools?
      • From: "Brian O'Brien" <email@hidden>
References: 
 >nested autorelease pools? (From: "Brian O'Brien" <email@hidden>)
 >Re: nested autorelease pools? (From: j o a r <email@hidden>)
 >Re: nested autorelease pools? (From: John Stiles <email@hidden>)
 >Re: nested autorelease pools? (From: j o a r <email@hidden>)

  • Prev by Date: Cocoa Heads Orange County initial meeting
  • Next by Date: Re: nested autorelease pools?
  • Previous by thread: Re: nested autorelease pools?
  • Next by thread: Re: nested autorelease pools?
  • Index(es):
    • Date
    • Thread