Re: NSOperationQueue
Re: NSOperationQueue
- Subject: Re: NSOperationQueue
- From: Mike Fischer <email@hidden>
- Date: Sun, 21 Sep 2008 23:40:28 +0200
Am 21.09.2008 um 22:46 schrieb John Love:
has wrote:
Getting back to the main discussion of the OP's threading/
NSOperationQueue problems, perhaps it would help if he backs up a
bit and explains in general terms what he's trying to achieve,
rather than focus on individual details of how he's currently
trying to do it? That way, folks might be able to suggest a better
overall solution, rather than getting bogged down in the details
of the current, potentially misconceived, approach.
Before I write a short answer to this good question .. Mike, I'm am
no longer crashing into the debugger and am down to trying to get
my -startCalculation into a separate thread. Also, I ditched -
waitUntilAllOperationsAreFinished in order to implement what you
stated, namely:
=====
I would expect you to queue an NSOperation in the loop and if you
really need to wait until all of them are done executing then you
could wait after the loop. Note though, that you would still be
blocking the main thread. But at least you would be taking
advantage of NSOperationQueue's ability to schedule multiple
operations in parallel depending on available system resources.
=====
Back to has' big picture question ...
has, I have a rather lengthy series of calculations to do,
hopefully in a separate thread. In my "main.m", I init my
NSOperationQueue as a global, but do not add any
NSInvocationOperation's to it. In my main thread, I call -
startCalculation to do exactly that. The very first statement in -
startCalculation is a for-loop with a row-counter, and for each
iteration of this counter I add one Operation to the queue. As my
sidebar to Mike stated, I ditched -
waitUntilAllOperationsAreFinished for each row in the for-loop for
Mike's reason above.
That's it,
John
I think what has meant was to really back up all the way. You still
seem to be dealing with the details of the existing code.
From what I can piece together you are apparently trying to do some
lengthy calculation(s) in Excel and that you don't want to block the
UI of your application while these calculation(s) are happening. (I
don't think you really told us what your ultimate goal is though?)
The following is based on this assumption.
If you want to take any advantage of multithreading in your app then
you must first figure out whether you can find a way to to your
calculation a) from a secondary thread and b) from multiple threads
at once.
- NSAppleScript will not work because it is limited to the main thread.
- The Appscript.framework may solve at least part of that problem but
I would still expect trouble on the Excel side when multiple requests
come in that manipulate similar or even the same data structures at
the same time. It seems likely that Excel will only process one
request at a time. I'm just guessing here though.
Once you have figured out if and how threading can be used to solve
your problem then you can start to design your application around
whatever limitations you found.
One likely scenario based on my guesses above could be that you can
do your calculation from a secondary thread (using
Appscript.framework instead of NSAppleScript) but that additional
threads will not get you any advantages. In that case you would need
to serialize the calls to your calculation routine. But using an
NSOperationQueue would not help here because it will schedule as many
NSOperations in parallel as system resources allow. For your needs a
more primitive queue would be more appropriate (although queueing and
dequeueing operations should be thread safe). You would have your
secondary thread grab the next item from the queue, process it and
the loop back to pull the next item from the queue, etc. Meanwhile
your UI would keep running on the main thread.
HTH
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
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