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

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

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

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 blockingGet()

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

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: [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

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

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

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

> *Sent:* Sunday, September 25, 2016 9:03 PM > *To:* Martin Buchholz <marti...@google.com> > *Cc:* concurrency-interest <concurrency-inter...@cs.oswego.edu>; > core-libs-dev <core-libs-dev@openjdk.java.net> > *Subject:* Re: [concurrency-interest] We need to add blocking

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

that was meant to read “After this method returns _*true*_, > subsequent calls …” > > > > David > > > > *From:* Concurrency-interest [mailto:concurrency-interest- > boun...@cs.oswego.edu] *On Behalf Of *Viktor Klang > *Sent:* Sunday, September 25, 2016 9:03

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... >>

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,

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

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

Behalf Of *Viktor Klang >> *Sent:* Sunday, September 25, 2016 9:03 PM >> *To:* Martin Buchholz <marti...@google.com> >> *Cc:* concurrency-interest <concurrency-inter...@cs.oswego.edu>; >> core-libs-dev <core-libs-dev@openjdk.java.net> >> *S

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,

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

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 >

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 >

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

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