On Sep 19, 2008, at 18:27 , Michael Ash wrote:
On Fri, Sep 19, 2008 at 2:41 PM, John Love <[EMAIL PROTECTED]>
wrote:
Michael Ash wrote:
Has it occurred to you that waiting for the operation to finish is
rather at odds with the idea of trying to run it asynchronously to
keep your program r
On Fri, Sep 19, 2008 at 2:41 PM, John Love <[EMAIL PROTECTED]> wrote:
> Michael Ash wrote:
>
>>
> Has it occurred to you that waiting for the operation to finish is
> rather at odds with the idea of trying to run it asynchronously to
> keep your program responsive?
>>
>
> Absolutely, but if
Michael Ash wrote:
>
Has it occurred to you that waiting for the operation to finish is
rather at odds with the idea of trying to run it asynchronously to
keep your program responsive?
>
Absolutely, but if the Thread is running in the background, it really
shouldn't matter to the main
On Tue, Sep 16, 2008 at 12:50 PM, John Love <[EMAIL PROTECTED]> wrote:
> [theQueue waitUntilAllOperationsAreFinished];
>From the documentation for this method:
"When called, this method blocks the current thread and waits for the
receiver's current and pending operations to finish executing. Whil
On Tue, Sep 16, 2008 at 12:50 PM, John Love <[EMAIL PROTECTED]> wrote:
> +
> Michael Ash wrote:
>
> When your application becomes unresponsive, pause it in the debugger
> and look at the backtraces of all the threads. (You can do this in a
> single step by typing "t a a bt" at the debugger cons
+
Michael Ash wrote:
When your application becomes unresponsive, pause it in the debugger
and look at the backtraces of all the threads. (You can do this in a
single step by typing "t a a bt" at the debugger console. This is a
shortcut for "thread apply all backtrace".) This should quickly te
On Tue, Sep 16, 2008 at 10:12 AM, John Love <[EMAIL PROTECTED]> wrote:
> Specifically, for example, while the queue is doing its calculation, I
> cannot press CMD-N to create a new document window. To continue with this
> specific example, CMD-N does do its thing, but only after the queue
> operati
Couple of things... you don't wanna create a queue every time. You
should
pretty much have just one queue that you add NSOperation objects to.
You
probably want to re-write this to be a singleton object that you get
from your
app controller or some other relevant place.
Queue initializatio
On Sep 15, 2008, at 5:18 PM, Quincey Morris wrote:
On Sep 15, 2008, at 14:35, Ken Thomases wrote:
It's possible that it's not safe to release a NSOperation until
after it returns YES to [NSOperation isFinished].
I don't think there needs to be anything specific in the
documentation. In t
On Sep 15, 2008, at 14:35, Ken Thomases wrote:
It's possible that it's not safe to release a NSOperation until
after it returns YES to [NSOperation isFinished].
I don't think there needs to be anything specific in the
documentation. In the absence of a documented exception, we should
ass
On Sep 15, 2008, at 1:04 PM, Quincey Morris wrote:
On Sep 15, 2008, at 10:31, Jason Coco wrote:
You /should/, however, autorelease your NSOperation since your queue
will retain it when you add it and release it when it completes.
This sounds plausible, but I can't find anything in the
docu
On Sep 15, 2008, at 14:04 , Quincey Morris wrote:
On Sep 15, 2008, at 10:31, Jason Coco wrote:
You /should/, however, autorelease your NSOperation since your queue
will retain it when you add it and release it when it completes.
This sounds plausible, but I can't find anything in the
docu
On Sep 15, 2008, at 10:31, Jason Coco wrote:
You /should/, however, autorelease your NSOperation since your queue
will retain it when you add it and release it when it completes.
This sounds plausible, but I can't find anything in the documentation
promising that NSOperationQueue will retain
On Sep 15, 2008, at 11:02 , John Love wrote:
I must be doing something terribly wrong, because when I start up
the NSOperationQueue that does some time consuming calculations, I
do not get back control of my application until after the lengthy
calculation is complete. Here are the relevant
Excerpts from John Love's message of Mon Sep 15 11:02:21 -0400 2008:
> I must be doing something terribly wrong, because when I start up the
> NSOperationQueue that does some time consuming calculations, I do not
> get back control of my application until after the lengthy calculation
> is co
Ken Thomases wrote:
[quote]
Note that if you don't make your operation "concurrent" in this
sense, but you queue it in an NSOperationQueue, that queue will still
run it asynchronously, in its own thread, concurrently with other
operations. It's just that, for non-"concurrent" operations,
NSOpera
On 8 Jun '08, at 5:26 PM, Wayne Shao wrote:
So what exactly I should do in the start() method??
Whatever you need to do to start the operation. It should return ASAP
since it's not being run on a background thread.
If I create a thread,
does the operation queue still enforce maxConcurren
On Jun 8, 2008, at 7:26 PM, Wayne Shao wrote:
So what exactly I should do in the start() method??
I think if you don't know, then you shouldn't be configuring your
operation as concurrent.
I think that Apple chose badly in describing operations as
"concurrent". What that really means is
I want to use NSOperationQueue to have at most 5 NSOperation running.
However, my operation is asynchronous.
>From the documentation:
If you are creating a concurrent operation, you need to override the
following methods:
-
start
-
isConcurrent
-
isExecuting
-
isFinis
19 matches
Mail list logo
