On 22/08/2010, at 7:03 AM, Roland King wrote:
> if( ![ NSThread isMainThread ] )
> [ NSMagicFunctionReturningAnInvocationForThisCurrentFunction()
> performSelectorOnMainThread:@selector( invoke ) withObject:nil
> waitUntilDone:NO ];
> else
> {
> // method performing code here
> }
>
> but there is of course no such function I'm aware of nor can I easily think
> how I'd write such a thing.
I can think of any number of alternatives to this sort of construction. The
GCD/Blocks solution being a "nice" way to achieve what you've outlined, but
which in itself is a truly horrible thing to behold.
Some ideas:
a). have a thread-safe receiver object that dispatches to another object on the
main thread that does the display work (or another instance of the same class?)
b). split the object into sets of external and internal methods where the
external methods can be called on any thread but redispatch to the internal
methods on the main thread.
c). Bottleneck all updates through a single method that can be invoked on the
main thread.
d). If the class can be constructed as a view (you mentioned it was a "display"
class, whatever that means) then it's fine to update internal state and call
-setNeedsDisplay: on any thread and have it handle the subsequent drawing on
the main thread.
If you are determined to use an NSInvocation, bear in mind that it incurs a
heavy performance penalty, but that the hidden parameter -cmd to any method is
its own selector.
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
