[concurrency-interest] Concurrency-interest Digest, Vol 26, Issue 7

David Holmes dcholmes at optusnet.com.au
Tue Mar 6 23:48:02 EST 2007

In early 2003 we thrashed out the details of the timed-blocking methods. At
that time we opined that anyone prepared to handle timeouts should also be
prepared to handle interrupts. We added awaitUninteruptibly as a concession
to the occasional need to have to wait for some condition regardless of
cancellation requests, and because it was a trivial implementation.
Generally the blocking methods do not have non-interruptible forms because
they are all considered cancellation points.

If we added awaitNanosUninterruptibly you could argue that all
timed-blocking methods should have an uninterruptible form. I don't think
they are needed often enough to warrant library inclusion.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Martin
> Buchholz
> Sent: Wednesday, 7 March 2007 1:31 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol
> 26,Issue 7
> Peter Veentjer wondered,
> "I was wondering why the Condition.awaitNanosUninterruptibly(long)
> method is missing. You are able to do an uninterruptible wait on the
> Condition without a timeout, but you are not able to do an
> uninterruptible wait on a Condition with a timeout."
> I've wondered the same thing myself in the past.
> Should Peter's static method be added to the JDK somewhere?
> Unfortunately, we cannot add new methods to existing interfaces.
> Martin
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list