Re: How to get the dispatch queue for the current thread's runloop?
Re: How to get the dispatch queue for the current thread's runloop?
- Subject: Re: How to get the dispatch queue for the current thread's runloop?
- From: Steve Sisak <email@hidden>
- Date: Sat, 28 Jan 2012 16:46:12 -0500
At 12:39 PM -0800 1/28/12, Jens Alfke wrote:
On Jan 28, 2012, at 11:35 AM, Steve Sisak wrote:
[self performSelector:@selector(performBlock:)
withObject:^{
NSLog(@"Done Later");
} afterDelay:1.0];
Don't you need to copy the block? Or is
-performSelector:withObject:afterDelay: smart enough to know to call
-copy instead of -retain on the block?
My understanding is that copying the block happens implicitly when
you call a function which takes a block as a parameter and doesn't
return synchronously -- and/or it's the callee's responsibility to
copy the block if it doesn't call it synchronously.
I would not be surprised if calling retain on a block passed as an
(id) does this as a side effect. (Sorry, I don't know the exact
implementation details)
Also, I'm not entirely happy with this solution because it's tied to
an object when it shouldn't need to be.
Agreed -- just trying to find a way to solve the problem with the API
available.
So your -doItLater: method only works in the class you declare it
in, and it has the side effect of keeping the receiver alive until
the block runs, even if it doesn't need to be (i.e. if the block
doesn't refer to 'self' at all.)
You (theoretically) could use any object which implements
-performBlock: as the target -- for instance you could have a
singleton BlockServer object which implements -performBlock: and use
that for the target of all requests.
Someone else had a solution that involved adding a category method
to NSObject to invoke the block, but that seems a bit kludgy too.
That would also work -- and you'd need to worry about collisions in
Obj-C's flat name space.
I'm still trying to figure this all out and poke around the boundary
conditions too. I'd love to hear from "someone who 'knows'". :-)
-Steve
_______________________________________________
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