RE: Providing synch/asynch API
RE: Providing synch/asynch API
- Subject: RE: Providing synch/asynch API
- From: Andy Klepack <email@hidden>
- Date: Wed, 26 Mar 2008 08:47:57 -0700
- Acceptlanguage: en-US
- Thread-topic: Providing synch/asynch API
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@hidden]
Sent: Tuesday, March 25, 2008 4:44 PM
To: Andy Klepack
Cc: email@hidden
Subject: Re: Providing synch/asynch API
On Tue, Mar 25, 2008 at 12:05 PM, Andy Klepack
<email@hidden> 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 (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