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 <kaspe...@gmail.com>
> To: nio-disc...@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.MAX_VALUE, TimeUnit.SECONDS); //ignore
> any interrupted exceptions
> }
>
> or like this
>
> public void close() {
> executor.shutdown();
> }
>
> - Kasper
>
