On 15 Jun 2012, at 00:54, Graham Cox wrote:
On 15/06/2012, at 3:56 AM, Dave wrote:
On 14 Jun 2012, at 05:12, Graham Cox wrote:
On 14/06/2012, at 8:03 AM, Dave wrote:
In assembler this would be implemented is using an "Exchange
Instruction" to alter the PC on the stack and cause it to return
to the correct place once the ASync Task (usually an interrupt)
had finished.
Ah, those were the days - push a calculated address on the stack
and do a 'RET' to cause a jump to that address... thankfully such
tricks are wholly unnecessary these days. In fact a simple
switch...case statement does the same job in most cases.
I'm not sure of the answer to your question though, seems to me
you could simply queue each task then the next executes as soon
as the one ahead of it finishes.
The point is you can't queue B until the data from A has been
obtained and that might take a long while. There are two ways to
deal with it, either have a call back from the lower level that
returns the data (in which case you have to specify an address/
selector to go to when the data has been obtained sucessfully), OR
you can invert the control and make the interface look as it is
demand based, even though the data is being obtained as and when
it is ready.
I can't really see the problem here. You can still queue the tasks,
even if the queued task doesn't have the data available when it's
queued - the data will be available by the time it comes to run, so
it can just ask for it then. It's really simple to create demand-
based data providers in Cocoa using informal or formal protocols,
delegation, or passing a predefined selector/target as you suggest.
Or using NSInvocation.
I can't see how queuing the Request would help or work in this case.
The point is that I don't know which request will be next because
it's dependent on the data returned by the previous request.
e.g.
myResponse = doTaskA;
if (myResponse.param == 1)
myResponse = doTaskB;
else
myResponse = doTaskC;
There is no point in queuing TaskB *and* TaskC since you don't know
which one you need to run until you get the response back from TaskA.
There are many solutions, there's probably no One True Way™ but
certainly you have the tools at your disposal - there are plenty of
solid reliable solutions that require no particular tricks, and
certainly nothing skanky of the sort you were reminiscing about!
The way I am doing it is not skanky in fact it works really well. The
code was already written using selector/target delgates and was a 2000
+ Lines of Code Class, doing it using an Infinite State Machines type
thing made it less than half that and the code is MUCH easier to
follow and MUCH easier to extend in the future.
All the Best
Dave
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
