Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

The completely less thread consuming alternative is call backs. VMS used/uses Asynchronous System Traps (ASTs) for everything in the 1980s. It was a very performant and friendly way to allow small software modules to be written to do one thing and used as the call back for asynchronous system

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

> On Sep 28, 2016, at 5:05 PM, Gregg Wonderly wrote: > > The completely less thread consuming alternative is call backs. This is a technique that we commonly used in a system that a group of use built in the 90s. The system had many variants on a number of different data flows through the s

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

> > I don't see any support in junit or testng for multi-threaded tests. TestNG has basic support on @Test for running a test method concurrently. This assumes synchronous code that does not perform complex coordination, e.g. simple writes into a ConcurrentMap. Specifically the annotation provide

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

If not a straight blocking method, a fluent conversion method to type R could be useful IMO: R to(Function, R> converter) { return converter.apply(this); } This way, who needs a blocking get can have a function prepared with a blocking operation: Function, T> blockingGet() { cs -> {

Re: We need to add blocking methods to CompletionStage!

On Sep 27, 2016 01:18, "Martin Buchholz" wrote: > > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang 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 r

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Seems legit -- Cheers, √ On Sep 26, 2016 23:29, "Attila Szegedi" wrote: > Not at all, you could just have a call to cancel() block until the future > completes. > > *ducks* > > Attila. > > > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > > > If that truely is the case then the only way of

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

I don't remember what happened in 2005, but records say that I wrote: """Why not .. - add to the spec of Future.cancel() a guarantee that subsequent calls to Future.isDone() always return true? """ which led to the spec: """After this method returns, subsequent calls to isDone()

Re: We need to add blocking methods to CompletionStage!

On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang 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 seri

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Not at all, you could just have a call to cancel() block until the future completes. *ducks* Attila. > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from cancel... > > -- > Cheer

Re: We need to add blocking methods to CompletionStage!

On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz wrote: > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > +1 > This also means that CompletionStage cannot extend Future. > +1 > I also would not wa

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

> On 25 Sep 2016, at 22:49, Martin Buchholz wrote: > ...Say you are implementing some existing function with a traditional > synchronous API. Your implementation is multi-threaded, but that's an > implementation detail. Before you return to the caller, you must wait for > the various parts o

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Cancellation: David, I can see your point. Future.cancel(true) was discussed 8/27/05 and the extra text was added to make it clearer that the state of Future after cancel is called is separate from the state of any associated thread or task. However, I think the added text corresponded too closely

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

016 9:03 PM > *To:* Martin Buchholz > *Cc:* concurrency-interest ; > core-libs-dev > *Subject:* Re: [concurrency-interest] We need to add blocking methods to > CompletionStage! > > > > > > > > On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang > wrote: >

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang wrote: > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break users, by making an immutable interface mutable. >> > > +1 > > >> This also means th

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 11:49 PM, Martin Buchholz wrote: > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > >> >> PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? >> C'mon, I know you're better than that! CompletionStage's design has nothing >> to do with Actor

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

boun...@cs.oswego.edu] *On Behalf Of *Joe Bowbeer > *Sent:* Monday, September 26, 2016 12:20 AM > *To:* David Holmes > *Cc:* Martin Buchholz ; concurrency-interest < > concurrency-inter...@cs.oswego.edu>; core-libs-dev < > core-libs-dev@openjdk.java.net> > > *Sub

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz wrote: > > > On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang > wrote: > >> If that truely is the case then the only way of implementing a readonly >> Future is by throwing an exception from cancel... >> > We the maintainers of j.u.c.Future have alw

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 2:22 PM, David Holmes wrote: > > Yet we somehow added the clarification with no regard as to whether cancel > returned true or not. That seems wrong. > Yikes! I had always assumed that cancel was not permitted to leave the Future incomplete, perhaps influenced by the wor

Re: We need to add blocking methods to CompletionStage!

On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang wrote: > > PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? > C'mon, I know you're better than that! CompletionStage's design has nothing > to do with Actors and if Single Responsibility Principle is considered > purism then I'm

RE: [concurrency-interest] We need to add blocking methods to CompletionStage!

: [concurrency-interest] We need to add blocking methods to CompletionStage! This statement regarding what happens after cancel is called is correct: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang wrote: > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from cancel... > We the maintainers of j.u.c.Future have always thought that canceling a Future will surely leave it completed. Of c

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

25, 2016 9:03 PM >> *To:* Martin Buchholz >> *Cc:* concurrency-interest ; >> core-libs-dev >> *Subject:* Re: [concurrency-interest] We need to add blocking methods to >> CompletionStage! >> >> >> >> >> >> >> >> On Sun,

RE: [concurrency-interest] We need to add blocking methods to CompletionStage!

; core-libs-dev Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang mailto:viktor.kl...@gmail.com> > wrote: On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz mailto:marti...@google.com> >

Re: We need to add blocking methods to CompletionStage!

No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. This also means that CompletionStage cannot extend Future. I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.ca

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

My limited understanding is that the original API was only CompletableFuture and that CompletionStage introduced as a compromise. It did not appear to be an attempt to strictly follow an interface-implementation separation, e.g. collections. As you said #toCompletableFuture() may throw an UOE, whic

Re: We need to add blocking methods to CompletionStage!

people are huge fans of parking threads then let's see if we can come to terms on a solution which doesn't compromise the solution for everyone else. The subject of this thread, "We need to add blocking methods to CompletionStage!", gave me a few questions: "who is 'we

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz wrote: > What is happening instead is API providers not using CompletionStage as > return values in public APIs because of the lack of convenient blocking, and > instead returning CompletableFuture, which is a tragic software engineering > failure.

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On 23 September 2016 at 07:27, Martin Buchholz wrote: > Thanks for the lesson, James! > > I took a look at the Scala/Akka/LightBend world. Even there, blocking > always remains a possibility, even if discouraged, e.g. > scala.concurrent.Future extends Awaitable (!), and > http://doc.akka.io/docs

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On 22 September 2016 at 06:43, Martin Buchholz wrote: > What is happening instead is API providers not using CompletionStage as > return values in public APIs because of the lack of convenient blocking, > and instead returning CompletableFuture, which is a tragic software > engineering failure. >

Re: We need to add blocking methods to CompletionStage!

> > Would not mind a CancellableCompletionStage interface > CancellableCompletionStage extends CompletionStage { > isCancelled(); > cancel(boolean) > } > > Just wanted to note. This is not just a question about functionality. It is also a signal to users about "hey this a computation you can ca

Re: We need to add blocking methods to CompletionStage!

On 21 September 2016 at 22:43, Martin Buchholz wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is > great. I'm a fan of the scala style Promise/Future split as described in > http://docs.scala-lang.org/overviews/core/futures.ht

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Thanks for the lesson, James! On Wed, Sep 21, 2016 at 3:57 PM, James Roper wrote: > On 22 September 2016 at 06:43, Martin Buchholz > wrote: > >> What is happening instead is API providers not using CompletionStage as >> return values in public APIs because of the lack of convenient blocking, >>

Re: We need to add blocking methods to CompletionStage!

Until now CS and CF have not appeared in Java SE API signatures, outside of the j.u.c package. They are, however, currently being proposed for use in API signatures for Java SE 9 [1][2], namely j.l.Process[Handle]::onExit, and more extensively in the proposed new HTTP Client. CF was chosen, in som

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Wed, Sep 21, 2016 at 2:38 PM, Pavel Rappo wrote: > On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz > wrote: > > What is happening instead is API providers not using CompletionStage as > > return values in public APIs because of the lack of convenient blocking, > and > > instead returning Com

We need to add blocking methods to CompletionStage!

(Sorry to re-open this discussion) The separation of a read-only CompletionStage from CompletableFuture is great. I'm a fan of the scala style Promise/Future split as described in http://docs.scala-lang.org/overviews/core/futures.html, but: we need to re-add (safe, read-only) blocking methods lik