Re: Apple Events and automatic AutoReleasePool managment
Re: Apple Events and automatic AutoReleasePool managment
- Subject: Re: Apple Events and automatic AutoReleasePool managment
- From: Jens Alfke <email@hidden>
- Date: Mon, 17 Mar 2008 12:34:42 -0700
On 17 Mar '08, at 11:38 AM, Andy Klepack wrote:
Does an 'event cycle' then include anything dispatched from a run
loop source? For instance, if I was to create a kqueue, create a run
loop source for it, and add that to the main run loop, does an
AutoReleasePool automatically get created before the handler is
called and destroyed after it returns?
In general, Objective-C callback methods are invoked with an
autorelease pool in place. There are exceptions, though (the code that
runs in a new NSThread is one example). But C callbacks invoked from
CoreFoundation or lower levels won't have autorelease pools.
So your kqueue callback needs to create its own autorelease pool,
because it's a C callback called from CoreFoundation (CFRunloop).
What about for invocations that result from DO communication in
which the incoming port is registered on the main run loop?
DO puts an autorelease pool on the stack before it calls into your
objects.
It's not that critical to make the right decision here immediately,
though. If you leave out an autorelease pool where one is needed,
you'll get lots of console warnings telling you so, and you can go
back and put one in. If you put in an autorelease pool where it isn't
needed, it's a tiny performance hit but won't hurt anything.
What's more important is to wrap all C callbacks in an @try block to
catch all exceptions. Throwing an exception out of your callback past
exception-unaware C code is practically guaranteed to mangle system
state and cause hard-to-debug crashes soon thereafter.
It's also important to catch exceptions in the top-level method of a
thread, since an uncaught exception without any handler on the stack
will cause your whole process to abort.
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden