Fibers, Futures, and Concurrency (oh my)

[markandrewfalco]

Ok I’ve been thinking a fair bit about fibers and futures. IIRC currently @Future/^ only suggests that the call be made async, and it is only async if the target is a service. I think we should strengthen this such at any @Future/^ ensures execution on a new fiber. Thus if the target is not a service then it is a new fiber from source service. I think for the end user this makes a lot more sense then saying a ^ call might be async or might not be. Also for things like ConcurrentHasMap, it means the const facade layer doesn’t need to internally (potentially needlessly) be adding ^ to each of its calls to the Partitions to ensure that if its caller wants to be able to go async it doesn’t get in the way. As part of this I expect we’d need to revisit the concurrency rules related to allowing green calls to a red service.

[ggleyzer]

Interesting... That would mean that if a fiber A comes to a call: "x.f^()", then A proceeds to the next op regardless of whether x is a service or not. The disadvantage of that is an increased cost of "in-service" call orchestration. The advantage is that if x is not a service, but "X.f()" has a service call on its own, than the old approach would effectively block A, while the new one would keep it non-blocking. Clearly, for any of that to differ from the current behavior, both A and x.f() would have to be @Concurrent

[markandrewfalco]

I think in order for it to be reasonably useful and also not deadlock prone we'll need to the revisit concurrency rules around allowing green fibers to run when there is a red fiber. Also we'll need to discuss what constitutes "the logical thread of execution", as I think that definition may need to be broadened to include intra-service fibers where fiber 2 needs to enter red code and fiber 1 is waiting on fiber 2's future.