Re: self and _cmd
Re: self and _cmd
- Subject: Re: self and _cmd
- From: Simon Stapleton <email@hidden>
- Date: Thu, 06 Sep 2001 14:38:45 +0100 (BST)
Quoting Ondra Cada <email@hidden>:
>
Simon,
>
>
>>>>>> Simon Stapleton (SS) wrote at Thu, 06 Sep 2001 13:27:08 +0100
>
(BST):
>
SS> What about using NSNotificationQueue to post a notification to
>
SS> yourself using NSPostWhenIdle? Seems cleaner to me than having
>
your
>
SS> app do stuff on a timed interval.
>
>
So far as I know, performSelector:withObject:afterDelay:0 does the
>
very same thing. And it is much simpler.
Ah. That would make sense.
>
Notifications are intended for a different task, although they
>
could be used this way too
Indeed.
>
SS> Of course, shoving all your background processing cack into a
>
SS> separate thread is the real solution in most cases. I can't
>
SS> think of a case where I'd want 'idle processing' to occur in
>
SS> the foreground.
>
By "foreground" you mean the main (and often only) application
thread, I guess?
Yep. The one that's doing the _displaying_. I maintain that for
any non-trivial (in computation terms) app, there should be a thread-
level separation between display and computation. But then I come
from a background or writing heavy duty apps where 250ms delays are
considered significant, and sub-second response times are waaaay too
slow.
>
Multithreading is a great tool, utterly irreplaceable in many
>
cases, but for the simplest "background tasks" -- of which in my
>
experience there is some good 70-80 per cent -- it's an unneeded
>
overkill.
Oh, definitely, but for scalability it's almost always better to do
background work in the background. It may be possible to do that one
little thing in the foreground _now_ but 3 years down the line when
you have to tear the entire application apart to put processing where
it belongs because it's been incrementally 'enhanced' over time, you
may well wish you'd multithreaded in the first place. Been there,
done that ;-)
<rant employer_inspired="100%">
There's really very little excuse for not doing things right 'first
time around' - even budgetary constraints pale away into nothingness
when you consider the cost of maintaining badly-designed code. Which
is what I'm currently doing.
</rant>
Simon
--
If the answer isn't obvious, the question is a distraction. Go find
an easier question.