sequenceFutures should complete immediately if given futures are completed

[wtmoose]

PMFuture *foo = [PMFuture futureWithResult:@YES];
PMFuture  *bar = [PMFuture sequenceFutures:@[foo]];

I would expect [bar isCompleted] to return YES. But it returns NO.

[dpratt]

Iif you're calling that in the thread that created it, it may not actually be completed yet. Sequence iterates over the input asynchronously - I'd add either a wait for 500 ms or so or await the result itself.

—
Sent from Mailbox for iPhone

On Mon, Mar 17, 2014 at 9:59 PM, wtmoose notifications@github.com wrote:

PMFuture *foo = [PMFuture futureWithResult:@YES];
PMFuture  *bar = [PMFuture sequenceFutures:@[foo]];

I would expect [bar isCompleted] to return YES. But it returns NO.

Reply to this email directly or view it on GitHub:
#1

[wtmoose]

Wouldn't it be a nice improvement if it could synchronously check the isCompleted status of the input first? It seems like the intuitive behavior to me. Anyway, I'm trying to avoid showing a loading indicator if the data is in memory and trying to do so elegantly. Will think about it some more.

[dpratt]

The problem arises that giving the isComplete accessor behavior in that manner implies that it would have to be a blocking call. I prefer to exclusively limit blocking to Await. 

It sounds like what you want is to know "is this future completed, and if not, will it be very soon?" The right way to do that is await with a very small timeout (say 10 ms or so) and call onConplete if the await times out. Await has little to no overhead - it blocks on a low level mutex and there's no thread context jump, so it might fit your usecase.
—
Sent from Mailbox for iPhone

On Mon, Mar 17, 2014 at 10:27 PM, wtmoose notifications@github.com
wrote:

Wouldn't it be a nice improvement if it could synchronously check the isCompleted status of the input first? It seems like the intuitive behavior to me. Anyway, I'm trying to avoid showing a loading indicator if the data is in memory and trying to do so elegantly. Will think about it some more.

Reply to this email directly or view it on GitHub:
#1 (comment)