Skip to content

Adding a fast-path for Await on already completed Futures #7768

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 27, 2019

Conversation

viktorklang
Copy link
Contributor

Avoids the overhead of using the BlockContext for already known-completed Futures.

(Correct version of #7767)

@scala-jenkins scala-jenkins added this to the 2.13.1 milestone Feb 18, 2019
@viktorklang viktorklang force-pushed the wip-improved-await-√ branch from ddb29d8 to f0ad303 Compare February 18, 2019 14:34
@SethTisue SethTisue modified the milestones: 2.13.1, 2.13.0-RC1 Feb 19, 2019
@SethTisue
Copy link
Member

SethTisue commented Feb 26, 2019

review by... @NthPortal? @tarsa? @WellingR?

@tarsa
Copy link

tarsa commented Feb 26, 2019

Hmmm, if we're checking if future is already completed then we can also check if the maximum wait duration is positive.

  final def ready[T](awaitable: Awaitable[T],
                     atMost: Duration): awaitable.type = {
    if (blockingNotNeeded(awaitable, atMost)) {
      awaitable.ready(atMost)(AwaitPermission)
    } else {
      blocking(awaitable.ready(atMost)(AwaitPermission))
    }
  }

  private def blockingNotNeeded(awaitable: Awaitable[_],
                                atMost: Duration): Boolean = {
    (awaitable.isInstanceOf[Future[_]] &&
    awaitable.asInstanceOf[Future[_]].isCompleted) ||
    (atMost match {
      case duration: FiniteDuration => duration.length <= 0
      // this returns true in case of Duration.Undefined
      case _ => !(atMost.toUnit(null) > 0.0)
    })
  }

Don't know the tradeoffs, though.

Copy link
Contributor

@NthPortal NthPortal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I agree with @tarsa that it could potentially be optimised further for non-positive durations

@viktorklang
Copy link
Contributor Author

@tarsa @NthPortal Agreed, there is a "second optimization step" which could include optimizing for other Awaitables, but I don't know of any off-hand so I'm deferring that for now.

Copy link
Contributor

@WellingR WellingR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I don't think optimizing for non-positive durations is needed, since I think it is very rare to use a non-positive duration.

@viktorklang viktorklang merged commit d64a789 into scala:2.13.x Feb 27, 2019
@viktorklang viktorklang deleted the wip-improved-await-√ branch February 27, 2019 20:26
@diesalbla diesalbla added the library:concurrent Changes to the concurrency support in stdlib label Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
library:concurrent Changes to the concurrency support in stdlib
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy