logo       

Re: JCiP Memoizer: msg#00032

java.jsr.166-concurrency

Subject: Re: JCiP Memoizer

On 10/18/06, Joe Bowbeer <joe.bowbeer@xxxxxxxxx> wrote:
> I think the existing cancellation exception handling would make more
> sense if the task were submitted to an executor. Then a forced
> shutdown of the executor, for example, could cause a cancellation
> exception.
>
> Btw, when I've coded this kind of thing in the past, I've usually
> finessed the problem by adding "throws Exception" to the method in
> question :-)
>

He he... in my case I must have no throws :-).

./alex
--
.w( the_mindstorm )p.

> On 10/18/06, David Holmes <dcholmes@xxxxxxxxxxxxxxx> wrote:
> > Alex,
> >
> > I have to concur with Tim. The intent was that interruption during ft.run()
> > implied cancellation and so there was a need to do clean-up of the cache
> > entry. But there is nothing to convert the interruption to a cancel()
> > request and so all that happens in the current case is that everyone who
> > calls f.get() will get ExecutionException with a cause of
> > InterruptedException.
> >
> > [...]
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@xxxxxxxxxxxxxxxxxxxx
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise