New select and Mutex algorithms

[ndkoval]

New select and Mutex algorithms

[qwwdfsad]

For the record, rebase on develop has rewritten the author of half of the commits, from a31621a to e38ca48

[qwwdfsad]

Also, ChannelUndeliveredElementSelectOldStressTest fails, please fix that as well, we would like to avoid having any flaking tests in the mainline

[ndkoval]

As for the flacking test, there was a problem in the test itself. Now the tests are green.

[qwwdfsad]

TODO for me: cleanup documentation when it's the time

[qwwdfsad]

Same here, should be left as is

[ndkoval]

It's non-trivial to have a default implementation. I would suggest performing a cast to AbstractChannel and invoking onReceiveOrNull after that, throwing an exception if the channel implementation is not ours.

[ndkoval]

I will do an unchecked cast to AbstractChannel, we have discussed this in Slack

[qwwdfsad]

Good point, will leave it as a documentation improvement

[qwwdfsad]

Also, please revisit SelectInstance being sealed as Oleg suggested

[qwwdfsad]

The only use of this function is tryResumeSend which only cares about whether it's success or not (=> should rely on trySelect).

If you are not using this function in new channels, please remove it and all around it

[ndkoval]

The current implementation performs the following check, so it cannot be replaced with trySelect:

send.trySelectResult == REREGISTER

[qwwdfsad]

Thanks

[dkhalanskyjb]

I think that the code would be much cleaner if we introduced a private sealed interface to represent the possible types of waiters. This would cost us one additional application per slow-path acquire, but get rid of Any, impossible error, etc.

[ndkoval]

I agree with you, but your suggestion requires either CancellableContinuation to implement this sealed interface or adding unsafe casts at every CancellableContinuation usage (in case onlyCancellableContinuationImpl implements the interface). I do not see a good solution, so I would keep the current code.

[qwwdfsad]

Dima, thanks, it's indeed worth doing. I'll try to do it separately in a branch with new channels, so the disturbance will be minimal. I have a prototype for selects only and it looks much more readable

[dkhalanskyjb]

The idea was to do something like this (pseudocode):

private sealed interface ResumableComputation {
  fun resume()
  fun disposeOnCancellation(handle: DisposableHandle)
}

private class CancellableContinuationAsResumable(
  val continuation: CancellableContinuation<Unit>
): ResumableComputation {
  ...
}

So, CancellableContinuation would not itself implement anything (though maybe this interface makes sense in general and it should), it would be wrapped in an adapter. The cost is one more allocation on the slow path.

[ndkoval]

It is better not to do this. With #3084 and continuation reusability, the suspension becomes exceptionally efficient, as it does not allocate new objects. The change you suggest breaks this property, evolving extra work for GC.

[qwwdfsad]

Please address Dmitry's comments and it's good to go

[ndkoval]

I went through Dmitry's comments and checked the ABI manually.

[hrach]

👏