Proposal: Concurrency for all, any, when

[ghost]

Proposal:

concurrency : UInt? = nil for all, any, when

ex: Lets say we want to make 1000 async requests, but with concurrency 10, i think this will be a useful feature

[shoumikhin]

Hi @umbri,

The thing is ‘all’ and other extensions do not control the order in which the promises get resolved, nor run them either, but just wait for them. There’s even no guarantees if promises passed to ‘all’ will all be resolved on a concurrent queue simultaneously. It totally depends on how you created those promises and on which queue would you invoke the block which will eventually trigger ‘fulfill’ or ‘reject’ with a particular promise. The following discussion may also be helpful: https://github.com/google/promises/issues/28#issuecomment-369095196

Let us know if there’s anything still unclear, happy to elaborate.

Thanks.

[ghost]

Hi @shoumikhin

Thank you for a quick reply,

About my proposal, I was sure that promise is not executed till you call .then on it, but after some tests I find my epic broken logic :)

1. If above is true, then my proposal is useless
2. If above is true, then I have one more question :)

How to create Promise like a closure, that will do something after invoke it example:

let closure = {
    print("I am closure")
}

... 

closure()

let promise = Promise {
    print("I am promise")
}

...

// only now it will be executed 
promise.then {

}

[ghost]

I think something like this will be a nice feature: https://github.com/mxcl/PromiseKit/blob/master/Sources/when.swift#L104

[shoumikhin]

I don't think anything like that would be possible, because then just subscribes as an observer for a promise state and has no side-effects on the promise behavior, like triggering some work blocks associated with the promise. Plus, there're actually no such blocks that a promise keeps that can be somehow invoked later, to begin with.

Promise is an extremely small and simple abstraction. I imagine you could build something more sophisticated on top of it to allow such "cold" subscription. But there're no plans to overcomplicate the existing lib at the moment.