Johan Andrén

Note that Patrik had opinions in https://github.com/akka/akka/issues/24951#issuecomment-384222068 but I disagree that having an alternative for idle means we also need to add the same, I think completing the other operators...

https://github.com/akka/akka/runs/6995218784?check_suite_focus=true#step:5:2351

https://github.com/akka/akka/actions/runs/3056918371/jobs/4931539053

I think it could just reschedule a new delay in that very uncommon case and skip the assert.

Isn't the problem that this scheduled timer only ever triggered if the deadline has already passed? https://github.com/akka/akka/blob/390e9f675b6d2f666be2dd15b87c84c870e8b625/akka-stream/src/main/scala/akka/stream/impl/Timers.scala#L270 Edit: no it isn't I read it wrong. Dang.

I found both the concurrency list discussions (and that SO response) to be a bit speculative. Searching a bit all mentions of nanoTime going backwards are old or refer to...

Can you explain a bit more what the problem this PR is trying to solve is? Did you observe performance problems with the composed operator?

I see, so it is to be able to determine and optimize iterable sources in for example Akka HTTP. @jrudolph is the new stage here useful for that?

Benchmarking this with the `InvokeWithFeedbackBenchmark` is pretty much the same as `main`/baseline. However that benchmark basically does a one-by-one queue offer. Would need some tweaking to do N parallel offers...

I agree that it could be worth it for the simplification rather than any perf improvement though.