Re: Making an NSMethodInvocation from the current method
Re: Making an NSMethodInvocation from the current method
- Subject: Re: Making an NSMethodInvocation from the current method
- From: Graham Cox <email@hidden>
- Date: Sun, 22 Aug 2010 18:31:31 +0200
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 (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