Re: Let the runloop process its queue during a long operation
Re: Let the runloop process its queue during a long operation
- Subject: Re: Let the runloop process its queue during a long operation
- From: Matt Neuburg <email@hidden>
- Date: Thu, 07 Oct 2010 08:33:37 -0700
- Thread-topic: Let the runloop process its queue during a long operation
On Thu, 7 Oct 2010 05:41:23 -0400, Dave Keck <email@hidden> said:
>
>For your situation, you shouldn't need to deal with the run loop
>directly. Normally you'd want to use a separate thread, NSOperation,
>etc., but since you're using AppleScript, that's out of the question
>since it's confined to the main thread.
Not true in Snow Leopard; AppleScript is now thread-safe. Moreover, use of
Apple events on a background thread was in fact always possible; thus, if
you use obj-appscript instead of NSAppleScript, aside from being happier
in other ways, you'll also be thread-safe going all the way back to Mac OS
10.3.
Again, I repeat my recommendation that the O.P. just stop worrying and use
NSOperation.
For an example, see my SyncMe2 application: it drives the Finder using
Apple events (via obj-appscript) to do lengthy copies, which can take many
minutes, and does not proceed to the next copy until the Finder has
finished with it; yet the interface is never frozen and the spinning
beachball never appears, because the AppleScript stuff is all happening in
the background. This is no different than what the O.P. is talking about.
NSOperation makes it all easy. m.
--
matt neuburg, phd = email@hidden, <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings
_______________________________________________
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