I was hoping to look at the problem from a more generic perspective where the operation itself was variable but the callback would be either in the same thread as they were created from or in the main thread itself.
For a more concrete example I'm working on an ObjC wrapper for a web service that my daemon uses. The web service class wraps calls to the actual web methods and returns the result objects hydrated from the results of the invocation. I'd like some of these methods to be synchronous and some to be asynchronous. I figure that the implementation can be simplified if I can come up with one mechanism under the hood and provide whichever variant I need. I am able to target Leopard and above. -Andy -----Original Message----- From: Kyle Sluder [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 4:44 PM To: Andy Klepack Cc: cocoa-dev@lists.apple.com Subject: Re: Providing synch/asynch API On Tue, Mar 25, 2008 at 12:05 PM, Andy Klepack <[EMAIL PROTECTED]> wrote: > I'm curious how people tackle this problem pre-Leopard and > performSelector:onThread:withObject:waitUntilDone: API Well you've got a couple of unresolved parameters: 1) Do your callbacks need to execute on the same thread they were created from, the detached thread, or either? 2) What non-trivial operation is your method performing? Does this operation perform blocking I/O or thunk down to another blocking API? 3) Can you target only Leopard? --Kyle Sluder _______________________________________________ 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 [EMAIL PROTECTED]
