On Fri, Oct 5, 2012 at 1:10 PM, David Holmes <david.hol...@oracle.com> wrote:
> On 5/10/2012 7:56 PM, Alan Bateman wrote:
>>
>>
>> Forwarding Kasper's mail to the right list.
>>
>> From: Kasper Nielsen <kaspe...@gmail.com>
>> To: nio-disc...@openjdk.java.net
>>
>> 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();
>> }
>
>
> That's really an arbitrary choice. What semantics do you want the close() to
> have?The least surprising from a user perspective. If a given auto closable resource can be in 3 states: running -> closing -> closed. And I have a resource where the closing phase can take multiple seconds. Would the user assume that when close() returned, the resource was in the closed state. Or could I just spawn a thread that did the actual close and immediately return control to the caller with the resource in the closing state. Given that any class I could find in the JDK that implements AutoCloseable blocks until the socket/filesystem/rowset/... is fully closed. I thought maybe using AutoCloseable was a bit of a stretch to use for closing a resource asynchronously. - Kasper > > Personally I don't think AutoCloseable is a good fit for an executor service > as the lifetime of an autocloseable is tied to a block of code and that > would be a rare usage for an executor service. I agree, I was just using the executor service as a rather poor example. Kasper
