Decouple futures completion from dispatchers

[yglukhov]

This sudden idea is pretty trivial. This PR restores old future completion behavior that doesn't rely on selectors, and fixes the recursion problem differently. callSoon is now reentrant and launches callback processing only for the first callback. The benefits are that futures are now self sufficient and don't need a completion proc to complete properly. This also simplifies the implementation of selectors as they now don't need to care about pending futures. I will clean up the selectors code in this regards as soon as this (and probably upcoming) is merged. Please review.
@Araq, @dom96, @zielmicha, @cheatfate.

[yglukhov]

@endragor, rumors say you could help test this. Could you please? =)

[zielmicha]

Looks good to me.

• it's not obvious that the code is correct (e.g. a function is not called more than once), maybe add some comments explaining why?
• I think getCallSoonProc should be removed, not deprecated

[yglukhov]

@zielmicha, ok, added a comment. Hopefully it clears the things up a bit.

I don't want to remove those procs to not introduce conflicts with dom's upcoming merge. All of those can later be removed completely from selectors along with pending callbacks logic. Though I could do that if @dom96 doesn't mind.

[cheatfate]

I'm just curious, for what reason the name of this PR is "Decouple futures completion from selectors".
Does selectors completing futures? Nope.
Does selectors calls callbacks? Nope.
Does selectors knows anything about futures? Nope.

[yglukhov]

Haha, good point, that should be "dispatchers" obviously.

[Araq]

@dom96 Please give some feedback.

[dom96]

This is fine in general, but it feels very unintuitive. I can see at least one potential issue (see comment)

Also I'm pretty sure we've changed this code a few times now, how can we be certain that this is the correct approach? I'm not confident that the semantics this code introduces won't cause other problems, mainly because this code isn't easy to understand.

Does anyone here know of how other async implementations deal with this problem? I think it's time we evaluate those to get a better insight.

[dom96]

Could we end up in a situation where this line raises, causing pendingCallbacks.len to be something higher than "1" and thus the above branch fails forever, leading to all callbacks not completing?

[Araq]

Ok, this means it's complex, will break code and seems to be another case of moving the problem around without solving much. IMHO this means this should be closed.

[dom96]

I think we should discuss it instead of just closing it and forgetting about it.

[yglukhov]

It's been a while, and I can see some downsides to this approach. Namely:

• As @dom96 noted, exceptions raised in callbacks are less deterministic (even if the reentrancy logic works), and we can end up in a situation when calling callSoon(myCB) raises an irrelevant exception.
• Infinitely mutually recursive callbacks will block the dispatcher from working.

IMO these issues have to be sorted, otherwise merging this pr is just moving problems around, as @Araq says.

Therefore, I suggest closing this. While it still remains a useful chunk of code, it is not sufficient on its own.

[dom96]

Alright. Closing.