question about ExecutorCompletionService

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

question about ExecutorCompletionService

yangjs
hi,all
  I have a Consumer poll task from ExecutorCompletionService ,this class has  no method such as isTerminated, when app is shutdown, I don't know when to shutdown my Consumer ,even if poll return null,.I can't accept consumer lost task . if  ExecutorCompletionService have method isTerminated as follow,thing will be simple. I can check when service poll return null and service isTerminated, my consumer can shutdown safely. is right??
why not provide such method ?
 
public boolean isTerminated(){
   return executor.isTerminated();
 }
 
 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Doug Lea
yangjs wrote:

> hi,all
>   I have a Consumer poll task from ExecutorCompletionService ,this
> class has  no method such as /isTerminated/, when app is shutdown, I
> don't know when to shutdown my Consumer ,even if poll return null,.I
> can't accept consumer lost task . if  ExecutorCompletionService have
> method isTerminated as follow,thing will be simple. I can check when
> service poll return null and service isTerminated, my consumer can
> shutdown safely. is right??
> why not provide such method ?
>  
> public boolean isTerminated(){
>    return executor.isTerminated();
>  }
>  
>  

This is a pretty good suggestion; thanks!
Except that ExecutorCompletionService requires only an Executor,
not an ExecutorService, and Executors don't necessarily
have lifetime control methods (shutdown, isTerminated, etc).
So in cases where people use some custom Executor that is
not also an ExecutorService, the method can't be implemented.

So the best we could do is add method
   public Executor getExecutor() { return executor; }
And you would then need to check termination using the ugly:
   ((ExecutorService)(ecs.getExecutor()).isTerminated();
(and being prepared for cast failure.)

We could in fact compatibly add method getExecutor() because
this is a concrete class and so doesn't impact other interfaces
etc. And it would be handy in those cases where you
don't otherwise have a reference to the executor used to create
the ExecutorCompletionService. But unfortunately, nearly all
uses of this would require casting of result, making it
a bit ugly. Perhaps there is some better way of going about
this with equivalent but nicer effect?

-Doug



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Dhanji R. Prasanna
How about using generics to type ExecutorCompletionService?
Something like:

class ExecutorCompletionService<EX extends Executor, V> {
//...

EX getExecutor()..

}

then you could do:
ecs = new ExecutorCompletionService<ExecutorService, ..>(..);
ecs.getExecutor().isTerminated();

It's not much but you avoid the ugly cast.

On 8/31/06, Doug Lea <[hidden email]> wrote:

> yangjs wrote:
> > hi,all
> >   I have a Consumer poll task from ExecutorCompletionService ,this
> > class has  no method such as /isTerminated/, when app is shutdown, I
> > don't know when to shutdown my Consumer ,even if poll return null,.I
> > can't accept consumer lost task . if  ExecutorCompletionService have
> > method isTerminated as follow,thing will be simple. I can check when
> > service poll return null and service isTerminated, my consumer can
> > shutdown safely. is right??
> > why not provide such method ?
> >
> > public boolean isTerminated(){
> >    return executor.isTerminated();
> >  }
> >
> >
>
> This is a pretty good suggestion; thanks!
> Except that ExecutorCompletionService requires only an Executor,
> not an ExecutorService, and Executors don't necessarily
> have lifetime control methods (shutdown, isTerminated, etc).
> So in cases where people use some custom Executor that is
> not also an ExecutorService, the method can't be implemented.
>
> So the best we could do is add method
>    public Executor getExecutor() { return executor; }
> And you would then need to check termination using the ugly:
>    ((ExecutorService)(ecs.getExecutor()).isTerminated();
> (and being prepared for cast failure.)
>
> We could in fact compatibly add method getExecutor() because
> this is a concrete class and so doesn't impact other interfaces
> etc. And it would be handy in those cases where you
> don't otherwise have a reference to the executor used to create
> the ExecutorCompletionService. But unfortunately, nearly all
> uses of this would require casting of result, making it
> a bit ugly. Perhaps there is some better way of going about
> this with equivalent but nicer effect?
>
> -Doug
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Remi Forax
Dhanji R. Prasanna a écrit :

> How about using generics to type ExecutorCompletionService?
> Something like:
>
> class ExecutorCompletionService<EX extends Executor, V> {
> //...
>
> EX getExecutor()..
>
> }
>
> then you could do:
> ecs = new ExecutorCompletionService<ExecutorService, ..>(..);
> ecs.getExecutor().isTerminated();
>
> It's not much but you avoid the ugly cast.

Not possible, the new ExecutorCompletionService will be not
backward compatible with the old one.

In Java, there is a compatibility between raw type
(type without type parameter) and parameterized type
but not between parameterized type with 1 parameter and
parameterized type with 2 parameters.

Rémi Forax

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Hanson Char
How about:

public class ExecutorCompletionService<V> implements CompletionService<V> {
...
    // return whatever Executor as the caller wish
    public <E extends Executor> E getExecutor() {
        return executor;
    }
}

Hanson

On 8/31/06, Rémi Forax <[hidden email]> wrote:
Dhanji R. Prasanna a écrit :

> How about using generics to type ExecutorCompletionService?
> Something like:
>
> class ExecutorCompletionService<EX extends Executor, V> {
> //...
>
> EX getExecutor()..
>
> }
>
> then you could do:
> ecs = new ExecutorCompletionService<ExecutorService, ..>(..);
> ecs.getExecutor().isTerminated();
>
> It's not much but you avoid the ugly cast.

Not possible, the new ExecutorCompletionService will be not
backward compatible with the old one.

In Java, there is a compatibility between raw type
(type without type parameter) and parameterized type
but not between parameterized type with 1 parameter and
parameterized type with 2 parameters.

Rémi Forax

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

tpeierls
In reply to this post by Doug Lea
On 8/31/06, Doug Lea <[hidden email]> wrote:
We could in fact compatibly add method getExecutor() because
this is a concrete class and so doesn't impact other interfaces
etc. And it would be handy in those cases where you
don't otherwise have a reference to the executor used to create
the ExecutorCompletionService. But unfortunately, nearly all
uses of this would require casting of result, making it
a bit ugly. Perhaps there is some better way of going about
this with equivalent but nicer effect?

It's not hard to roll your own:

public class TrackedExecutorCompletionService<V, E extends Executor>
        extends ExecutorCompletionService<V> {

    private final E exec;

    public TrackedExecutorCompletionService(E exec) {
        super(exec);
        this.exec = exec;
    }

    public TrackedExecutorCompletionService(
            E exec, BlockingQueue<Future<V>> queue) {

        super(exec, queue);
        this.exec = exec;
    }

    public E getExecutor() { return exec; }
}

--tim

On 8/31/06, Doug Lea <[hidden email]> wrote:
yangjs wrote:

> hi,all
>   I have a Consumer poll task from ExecutorCompletionService ,this
> class has  no method such as /isTerminated/, when app is shutdown, I
> don't know when to shutdown my Consumer ,even if poll return null,.I
> can't accept consumer lost task . if  ExecutorCompletionService have
> method isTerminated as follow,thing will be simple. I can check when
> service poll return null and service isTerminated, my consumer can
> shutdown safely. is right??
> why not provide such method ?
>
> public boolean isTerminated(){
>    return executor.isTerminated();
>  }
>
>

This is a pretty good suggestion; thanks!
Except that ExecutorCompletionService requires only an Executor,
not an ExecutorService, and Executors don't necessarily
have lifetime control methods (shutdown, isTerminated, etc).
So in cases where people use some custom Executor that is
not also an ExecutorService, the method can't be implemented.

So the best we could do is add method
   public Executor getExecutor() { return executor; }
And you would then need to check termination using the ugly:
   ((ExecutorService)(ecs.getExecutor()).isTerminated();
(and being prepared for cast failure.)


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Remi Forax
In reply to this post by Hanson Char
Hanson Char wrote:

> How about:
>
> public class ExecutorCompletionService<V> implements
> CompletionService<V> {
> ...
>     // return whatever Executor as the caller wish
>     public <E extends Executor> E getExecutor() {
>         return executor;
>     }
> }
>
> Hanson

???,
i don't a big difference between
(ExecutorService)executionService.getExecutor();
and
executionService.<ExecutorService>getExceutor(); +an unsafe cast in
getExecutor()

Rémi

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Hanson Char
The difference is you could do something like:

        ExecutorCompletionService ecs  = ...
        ExecutorService es = ecs.getExecutor();

        if (es.isTerminated()) {
           ...
        }

No casting needed.

Hanson

On 8/31/06, Rémi Forax <[hidden email]> wrote:
Hanson Char wrote:

> How about:
>
> public class ExecutorCompletionService<V> implements
> CompletionService<V> {
> ...
>     // return whatever Executor as the caller wish
>     public <E extends Executor> E getExecutor() {
>         return executor;
>     }
> }
>
> Hanson

???,
i don't a big difference between
(ExecutorService)executionService.getExecutor();
and
executionService.<ExecutorService>getExceutor(); +an unsafe cast in
getExecutor()

Rémi

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: question about ExecutorCompletionService

Hanson Char
>     public <E extends Executor> E getExecutor() {
>         return executor;
>     }

should be:

     public <E extends Executor> E getExecutor() {
         return (E)executor;  // casting done here once and for all;
     }

Hanson

On 8/31/06, Hanson Char <[hidden email]> wrote:
The difference is you could do something like:

        ExecutorCompletionService ecs  = ...
        ExecutorService es = ecs.getExecutor();

        if (es.isTerminated()) {
           ...
        }

No casting needed.

Hanson

On 8/31/06, Rémi Forax <[hidden email]> wrote:
Hanson Char wrote:

> How about:
>
> public class ExecutorCompletionService<V> implements
> CompletionService<V> {
> ...
>     // return whatever Executor as the caller wish
>     public <E extends Executor> E getExecutor() {
>         return executor;
>     }
> }
>
> Hanson

???,
i don't a big difference between
(ExecutorService)executionService.getExecutor();
and
executionService.<ExecutorService>getExceutor(); +an unsafe cast in
getExecutor()

Rémi

_______________________________________________
Concurrency-interest mailing list
[hidden email]
<a href="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest