| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/library/scala/concurrent/Promise.scala
test/files/jvm/future-spec/PromiseTests.scala
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calling `completeWith` when the `DefaultPromise` is already completed,
leads to callbacks not being properly executed.
This happened because `Future.InternalCallbackExecutor` extends
`BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
when in this case it is sync, and if there is an exception thrown
by executing the batch, it creates a new batch with the remaining
items from the current batch and submits that to `unbatchedExecute`
and then rethrows, but if you have a sync `unbatchedExecute`, it will
fail since it is not reentrant, as witnessed by the failed `require`
as reported in this issue.
This commit avoids problem by delegating `completeWith` to
`tryComplete`, which has the effect of using `onComplete` +
`tryComplete` i.s.o. `complete`, which means that when it fails
(because of a benign race condition between completers) it won't
throw an exception.
It has been tested by the minimized reproducer.
[1] Actually, in the 2.10.x branch where this patch is starting out,
"The BatchingExecutor trait had to be inlined into
InternalCallbackExecutor for binary compatibility.". This comment
will be more literally correct in the context of 2.11.x and beyond
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- `def transform[S](f: Try[T] => Try[S])(implicit executor: ExecutionContext): Future[S]`
- `def transformWith[S](f: Try[T] => Future[S])(implicit executor: ExecutionContext): Future[S]`
- `def flatten[S](implicit ev: T <:< Future[S]): Future[S]`
- `def zipWith[U, R](that: Future[U])(f: (T, U) => R)(implicit executor: ExecutionContext): Future[R]`
Add missing utilities:
- `val unit: Future[Unit]` in `object Future`
- `object never extends Future[Nothing]` in `object Future`
- `def defaultBlockContext: BlockContext` in `object BlockContext`
- `def toString: String` on stdlib implementations of `Future`
Refactors:
- the `scala.concurrent.Future` trait to not explicit create any `Promises`,
so that implementations can control implementation type,
this is mainly facilitated through adding of the `transform` and `transformWith` methods.
- the implementation of `ExecutionContextImpl` has been cleaned up
- the `scala.concurrent.impl.DefaultPromise` has been reimplemented to not use `sun.misc.Unsafe`
Securing:
- Add a self-check in `completeWith` and `tryCompleteWith` to avoid cycles in trait Promise
- Capping the maximum number of threads for the global `ExecutionContext` to the max parallelism
- Implementing (almost) all `Future` combinators on `transformWith` and `transform` means
that `DefaultPromise` linking works on both `(flat)map` and `recover(With)`
- Nested `blocking {}` should not spawn extra threads beyond the first.
Removes:
- the private `internalExecutor` method in favor of an import in trait `Future`
- the private `internalExecutor` method in favor of an import in trait `Promise`
- the `AtomicReferenceFieldUpdater` in `AbstractPromise` since we're using `Unsafe`
- `scala.concurrent.impl.Future` is no longer needed
Deprecates:
- `Future.onSuccess` - discourage the use of callbacks
(and is also redundant considering `foreach` and `onComplete`)
- `Future.onFailure` - discourage the use of callbacks
(and is also redundant considering `onComplete` and `failed.foreach`)
- `ExecutionContext.prepare` - it was ill specced and it is too easy to forget to call it
(or even know when to call it or call it more times than needed)
- All classes in scala.concurrent.forkjoin. Scala 2.12 will be Java 8+ and as such the jsr166e
should be used as included in java.util.concurrent.
Reimplements:
- `failed` - in terms of `transform`
- `map` - in terms of `transform`
- `flatMap` - in terms of `transformWith`
- `recover` - in terms of `transform`
- `recoverWith` - in terms of `transformWith`
- `zip` - in terms of `flatMap` + `map`
- `fallbackTo` - in terms of `recoverWith` + `recoverWith`
- `andThen` - in terms of `transform`
Miscellaneous:
- Giving the threads of `ExecutionContext.global` sensible names
- Optimizes `object Future.successful` and `object Future.failed` are now separate implementations,
to optimize for the result, avoiding doing work for the "other branch".
- Optimizes `compressedRoot()` by avoiding double-calls to volatile get.
Documentation:
- Almost all methods on `Future` and `Promise` have been revisited and had their ScalaDoc updated
Tests:
- Yes
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One last flurry with the broom before I leave you slobs to code
in your own filth. Eliminated all the trailing whitespace I
could manage, with special prejudice reserved for the test cases
which depended on the preservation of trailing whitespace.
Was reminded I cannot figure out how to eliminate the trailing
space on the "scala> " prompt in repl transcripts. At least
reduced the number of such empty prompts by trimming transcript
code on the way in.
Routed ConsoleReporter's "printMessage" through a trailing
whitespace stripping method which might help futureproof
against the future of whitespace diseases. Deleted the up-to-40
lines of trailing whitespace found in various library files.
It seems like only yesterday we performed whitespace surgery
on the whole repo. Clearly it doesn't stick very well. I suggest
it would work better to enforce a few requirements on the way in.
|
| | | |
|
| |/
|
|
|
|
|
| |
for the purpose of being consistent.
Also switches to Future.successful iso
Promise.successful(..).future for brevity
in implementation code.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Developed by Viktor Klang and Havoc Pennington
- add Promise.isCompleted
- add Future.successful and Future.failed
- add ExecutionContextExecutor and ExecutionContextExecutorService for Java interop
- remove defaultExecutionContext as default parameter value from promise and future
- add ExecutionContext.Implicits.global which must be explicitly imported, rather
than the previous always-available value for the implicit EC
- remove currentExecutionContext, since it could create bugs by being
out of sync with the implicit ExecutionContext
- remove Future task batching (_taskStack) and Future.releaseStack
This optimization should instead be implemented either in
a specific thread pool or in a specific ExecutionContext.
Some pools or ExecutionContexts may not want or need it.
In this patch, the defaultExecutionContext does not
keep the batching optimization. Whether it should
have it should perhaps be determined through benchmarking.
- move internalBlockingCall to BlockContext and remove currentExecutionContext
In this patch, BlockContext must be implemented by Thread.currentThread,
so the thread pool is the only place you can add custom hooks
to be run when blocking.
We implement BlockContext for the default ForkJoinWorkerThread in terms of
ForkJoinPool.ManagedBlocker.
- add public BlockContext.current and BlockContext.withBlockContext
These allow an ExecutionContext or other code to override
the BlockContext for the current thread. With this
API, the BlockContext is customizable without
creating a new pool of threads.
BlockContext.current is needed to obtain the previous
BlockContext before you push, so you can "chain up" to
it if desired.
BlockContext.withBlockContext is used to override the context
for a given piece of code.
- move isFutureThrowable into impl.Future
- add implicitNotFound to ExecutionContext
- remove default global EC from future {} and promise {}
- add ExecutionContext.global for explicit use of the global default EC,
replaces defaultExecutionContext
- add a timeout to scala-concurrent-tck tests that block on SyncVar
(so tests time out rather than hang)
- insert blocking{} calls into concurrent tck to fix deadlocking
- add NonFatal.apply and tests for NonFatal
- add OnCompleteRunnable marker trait
This would allow an ExecutionContext to distinguish a Runnable originating
from Future.onComplete (all callbacks on Future end up going through
onComplete).
- rename ListenerRunnable to CallbackRunnable and use for KeptPromise too
Just adds some clarity and consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Port of a pull request originally submitted by @havocp.
- declare the invariant that all app callbacks have an
associated ExecutionContext provided at the place
the callback is passed to a method on Future
- always run callbacks in their associated EC
- since all callbacks have their own EC, Promise
does not need one
- "internal" callbacks don't need to defer execution either
since we know the ultimate app callback will do so,
therefore we can use an immediate executor for these
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Match @param/@tparam names to the actual parameter name
- Use @tparam for type parameters
- Whitespace is required between `*` and `@`
- Fix incorrect references to @define macros.
- Use of monospace `` and {{{}}} (much more needed)
- Remove `@param p1 ...` stubs, which appear in the generated docss.
- But, retainsed `@param p1` stubs, assuming they will be filtered from
the generated docs by SI-5795.
- Avoid use of the shorthand `@param doc for the solitary param`
(which works, but isn't recognized by the code inspection in IntelliJ
I used to sweep through the problems)
The remaining warnings from `ant docs` seem spurious, I suspect they are
an unintended consequence of documenting extension methods.
[scaladoc] /Users/jason/code/scala/src/library/scala/collection/TraversableOnce.scala:181: warning: Variable coll undefined in comment for method reduceOption in class Tuple2Zipped
[scaladoc] def reduceOption[A1 >: A](op: (A1, A1) => A1): Option[A1] = reduceLeftOption(op)
[scaladoc] ^
|
| | |
|
| |
|
|
| |
racing completeWiths as a problem or not.
|
| |
|
|
| |
completeWith doesn't crash on multiple attempts.
|
| | |
|
| | |
|
| |
|
|
|
| |
Removed some methods from execution contexts.
Changed Awaitable interface.
|
| |
|
|
|
|
|
| |
Removed all the trailing whitespace to make eugene happier.
Will try to keep it that way by protecting at the merge level.
Left the tabs in place because they can't be uniformly changed
to spaces, some are 2, some are 4, some are 8, whee.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
methods.
|
| |
|
|
| |
files.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
execution-context
Conflicts:
src/library/scala/concurrent/Future.scala
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
package. Factor commonalities of promises and tasks into Completable.
|
| | |/
|/| |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
