Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completed set before the task has actually completed #58

Closed
leewinder opened this issue Aug 27, 2014 · 5 comments
Closed

Completed set before the task has actually completed #58

leewinder opened this issue Aug 27, 2014 · 5 comments

Comments

@leewinder
Copy link

[BFTask waitUntilFinished] shows this quite clearly. Fire off a few tasks, then call waitUntilFinished. The call to wait... will continue (and the task will be set to completed) before the execution block has been called.

This is due to [self runContinuations] always being called after completed/cancelled etc. being set. As a result.

I'm wondering if this is due to thread contention if the was called on the same thread as the executor block, but at the moment the behaviour seems incorrect and results in a lot of additional checks to make sure the task has actually finished.

@josephearl
Copy link

I'm not sure I understand, [BFTask waitUntilFinished] waits until the current task is completed, and if it completed successfully you will be immediately able to access the result.

Continuations may run after waitUntilFinished has returned, but those are for following tasks and not the current task so I see no issue there.

@leewinder
Copy link
Author

In this specific case, I expected the execution block to be called before [BFTask waitUntilFinished] returned which isn't the case. I expect this as I need to use the results of that block immediately after the call to [BFTask waitUntilFinished] on the same thread.

Continuations do continue for other tasks within the queue, thats fine and as expected, but this refers to the specific task being waited on.

@josephearl
Copy link

If you do something like:

BFTask *task = [client findAsync:query];
[task continueWithSuccessBlock:^id(BFTask *task) {
  NSLog(@"Continuation has run");
  return nil;
}]
[task waitUntilCompletion];

then when waitUntilCompletion returns the continuation will not have executed yet (and the message will not have been logged).

What you need is to do use the task returned from continueWithBlock:

BFTask *task = [client findAsync:query];
BFTask *continuationTask = [task continueWithSuccessBlock:^id(BFTask *task) {
  NSLog(@"Continuation has run");
  return nil;
}]
[continuationTask waitUntilCompletion];

then waitUntilCompletion will not return until the continuation has run (and message logged).

@leewinder
Copy link
Author

Ok, thats useful to know. The behaviour of my initial structure still seems incorrect though, but maybe that's just a documentation issues.

I say that because I have the same code paths for both async and (for testing) synchronous calls with an optional call to [task waitUntilCompletion], which to me made the most sense.

But like I say, maybe it just needs to be documented.

@ghost
Copy link

ghost commented Feb 10, 2015

Thanks guys!
Closing this one, as the issue seems to be resolved now.
Feel free to reopen or send a Pull Request if you think there is anything actionable here.

@ghost ghost closed this as completed Feb 10, 2015
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants