Re: Understanding the Run loop idea and the updating of controls during long operations
Re: Understanding the Run loop idea and the updating of controls during long operations
- Subject: Re: Understanding the Run loop idea and the updating of controls during long operations
- From: eveningnick eveningnick <email@hidden>
- Date: Mon, 8 Nov 2010 21:19:41 +0200
>
> On >10.6 you can safely execute Apple scripts from a secondary thread (see
> previous thread on this matter).
>
> Well, I just checked this using an NSOperation object which executes a
> script. The operation can be alternatively executed on the main thread
> scheduled by the global queue [NSOperation mainQueue] or it can be executed
> on a secondary thread scheduled by any queue which you get via
> [[NSOperationQueue alloc] init]. There is no noticeable difference in the
> execution time of the script, which takes about 15 seconds. (As a contrived
> example, the script launches TextEdit which itself opens a text file of
> about several kByte. The script counts the words, builds a list of words and
> an internal sort routine sorts these words and returns the sorted list.)
>
> The Cocoa app is just a few lines - and it doesn't require any thoughts on
> how to handle the run loop -- there is simply no need for this. There is no
> need for synchronization as well, unless you schedule a number of operations
> concurrently which modify the same object (say a file, or whatever).
>
> I should note however, that a script is not "cancelable" -- it performs
> "atomically" regarding the NSOperation's main method. So, in order to make
> the NSOperation's main method interruptible, you need to partition your work
> in a sequence of smaller actions executed by one or more scripts. Then call
> them in sequence -- preferable in a loop. Before you execute the next script
> you check the cancellation state of the NSOperation. Just return from -main
> when someone had cancelled the operation. The operation can send messages
> about the progress to its delegate (note: custom NSOperation, which defines
> also an appropriate delegate protocol) in every loop as well, and may return
> a result when it eventually finished.
>
> When the NSOperation executes on a secondary thread, the app's main thread
> isn't blocked and receives and processes input without any noticeable delay.
>
> The most challenging task is probably to partition a given script, so that
> the task becomes interruptible when executed in a NSOperation.
>
Thank you Andreas, i really appreciate your work. I dont really know, why
did it slow down in my case.
Well now we know it should work without any slowdown :)
My application has to be able to be launched in Leopard as well, therefore
i've left this multithreading approach and i just run the runloop
periodically inbetween "applescript chunks" during that long operation.
Fortunately, it works fine so far, updating all the controls "in time".
_______________________________________________
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