On 2013 Nov 14, at 08:01, Graham Cox wrote:
> Grrr.
OK, a couple really wild ideas. I don’t know whether or not you’re working
with NS Persistent Document, Core Data.
You know that when NSPersistentDocument reverts, it closes and releases all
document windows and creates new ones. But pla
Grrr.
OK, I’ve got a beautiful progress-monitoring solution that works lovely for
background threads with minimal impact on that thread (or for work that is done
in chunks on the main thread), and it’s doing great service for tracking a
lengthy file open (as a side note, I’ve tracked down some
On 12 Nov 2013, at 8:00 pm, Quincey Morris
wrote:
> Perhaps the question is why you’re using ‘performSelector’ for this at all,
> other than historical inertia.
Hmm, that just about sums it up I suppose.
> Now, it would be more natural to use GCD for this — dispatch a block onto the
> main
On Nov 12, 2013, at 06:26 , Graham Cox wrote:
> I’m just thinking about the use of
> -performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best
> way to think about the waitUntilDone parameter.
Perhaps the question is why you’re using ‘performSelector’ for this at all,
other
Le 12 nov. 2013 à 17:45, Graham Cox a écrit :
>
> On 12 Nov 2013, at 4:12 pm, Jean-Daniel Dupas wrote:
>
>> My rule is simply to never pass NO
>
>
> Did you mean YES? (i.e. always pass NO). Others seem to be saying the
> opposite.
>
My bad, Of course, always pass NO and never wait.
> —G
On 12 Nov 2013, at 4:12 pm, Jean-Daniel Dupas wrote:
> My rule is simply to never pass NO
Did you mean YES? (i.e. always pass NO). Others seem to be saying the opposite.
—Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not
On Nov 12, 2013, at 6:26 AM, Graham Cox wrote:
> I assume if I pass NO, the request is queued and processed once per event
> loop. If I pass YES, there is some sort of lock which sleeps my thread until
> the main thread completes the task.
Right.
> So passing NO, my worker thread can proceed
On 12 Nov, 2013, at 10:26 pm, Graham Cox wrote:
> Is this just one of those cases where you have to judge the best approach, or
> is there a better way to determine when to pass YES or NO?
>
> Currently, I generally pass NO, and my worker threads are not updating the
> progress too often anyw
Le 12 nov. 2013 à 15:26, Graham Cox a écrit :
> I’m just thinking about the use of
> -performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best
> way to think about the waitUntilDone parameter. The situation is updating a
> UI from another thread, using this to punt the upda
I’m just thinking about the use of
-performSelectorOnMainThread:withObject:waitUntilDone:, and what is the best
way to think about the waitUntilDone parameter. The situation is updating a UI
from another thread, using this to punt the update to the main thread (in fact
the progress bar situatio
10 matches
Mail list logo
