On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang <viktor.kl...@gmail.com> wrote:
> >> > Test methods, >> > > Yeah, I thought so as well, but it turns out that when you have tons of > async tests, not being able to start new tests until either that timeout or > result makes for a very slow test suite, so that's why most serious test > frameworks are growing support for dealing with async code. Then all you > want to be able to limit is work-in-progress (sloppily called parallelism) > I don't see any support in junit or testng for multi-threaded tests. jtreg uses the strategy of having a set of reusable JVM processes, each of which is running only one test at a time, which provides "pretty good" isolation, and seems to work well. > main methods >> > > That's a common scenario, but one that can be solved by having > non-daemonic pooled worker threads. > Do you have docs for such a thread pool? > and unix process reapers are all examples where it's reasonable to block >> forever. >> > > What about waitpid() + WNOHANG? > Are you suggesting periodic polling is better than blocking? > PPPPS: "I think it's unreasonable to not provide this for users >>> (especially when we can do so more efficiently)." <- If efficiency is >>> desired then blocking is definitely not the right solution. >>> >> >> What about efficiently providing isComplete? >> > > In my experience isComplete is virtually useless without being able to > extract the value, in which case you may as well introduce a non-blocking > `Optional<T> poll()` > Do you support adding the Polling methods from http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html to CompletionStage, i.e. isDone and getNow? > The result may already be available without actually blocking. It may >> even be known to be available immediately. One would like to get the value >> without additional allocation. >> > > I've seen that use-case :), and it tends to either be a situation where > the value is available by pure luck (or…scheduling artifacts) or when one > is keeping CompletionStages where strict values could be kept instead > (think rebinding a value on completion). > > Reading what your'e writing, may I dare propose that what you're after is > something along the lines of a: PollableCompletionStage which sits in > between CompletionStage and CompletableFuture? > I've been waffling! Right now, I'm leaning towards having Java APIs return fully mutable CompletableFutures as Benjamin and Pavel suggested upthread. Why? Because a completion stage can be thought of as all of: - a consumer of an upstream value - a subscription to the event that makes the upstream value available, and - the producer of a possible value for downstream consumers. Cancellation could be interpreted as a request to unsubscribe from upstream producer or a notification to downstream consumers that no value will be forthcoming, or both. Here's a problem with jdk9 minimalCompletionStage: even if you are happy with the minimality of the source stage (perhaps it's shared) you might want downstream stages to be mutable, but the methods such as thenApply also create minimal completion stages. If you want to convert to a mutable future, you can try calling toCompletableFuture, but there's no guarantee that will work, even if it doesn't throw UOE. You can hand-construct a CompletableFuture which is then completed in a Runnable via thenRun, but then this is opaque to the CompletableFuture implementation, and implementation features such as stack overflow prevention will be ineffective. So right now I'm OK with e.g. Process#onExit simply returning CompletableFuture.
