Fwd: AutoCloseable blocking or not (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Oct 5 10:57:34 UTC 2012

I would say that spec does not tell you anything about the blocking contract for try-with-resources, so as far as you are OK with the semantics outlined in JLS 14.20.3, you are good to go either way. Another example of blocking close() would be releasing the object in question to synchronized cache, which is potentially blocking.

BTW, while awaiting shutdown looks cleaner, there are some nasty complications if the workers in thread pool are ignoring interrupts, in which case you can block indefinitely. Not waiting for termination may silently leave some of threads running (I find it enlightening to find stale threads burning the CPU for days on production systems, while application thinks they are stopped.) Hence, either way of implementing TPE.close() as the standard method has its drawbacks, the users have to choose either one that fits their use case.

-Aleksey.

On 10/05/2012 01:56 PM, Alan Bateman wrote:

Forwarding Kasper's mail to the right list. -------- Original Message -------- Subject: AutoCloseable blocking or not Date: Fri, 5 Oct 2012 11:42:35 +0200 From: Kasper Nielsen <kasperni at gmail.com> To: nio-discuss at openjdk.java.net

Hi, I have a question about the AutoCloseable interface. Since I cannot find any mention about how asynchronously closeable resources should be handled. Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable. When close() returned should the executor be in the shutdown phase or in the terminated phase? In other words should I implement close() like this (which I believe) public void close() { executor.shutdown(); executor.awaitTermination(Long.MAXVALUE, TimeUnit.SECONDS); //ignore any interrupted exceptions } or like this public void close() { executor.shutdown(); } - Kasper

More information about the core-libs-dev mailing list