ThreadPoolExecutor and finalization

[Peter Levart]

On 11/01/17 13:34, David Holmes wrote:
> On 1/11/2017 10:20 PM, Peter Levart wrote:
>> On 11/01/17 10:04, David Holmes wrote:
>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>>> cycle need any kind
>>>>>> of cleanup.  I would work toward a model that encapsulates the 
>>>>>> reference to a native resource
>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>> described here and in the
>>>>>> thread on zip.
>>>>>>
>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>> improve robustness
>>>>>> by avoiding dependencies and opportunities for entanglements and 
>>>>>> bugs due to exceptions
>>>>>> and other failures.
>>>>>>
>>>>>> In the case of TPE, the native resources are Threads, which keep 
>>>>>> running even if they are
>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>> I don't know the Executor code well enough to do more than 
>>>>>> speculate, but would suggest
>>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>>
>>>>> Threads are not native resources to be managed by Cleaners! A live 
>>>>> Thread can never be cleaned. A dead thread has nothing to clean!
>>>>
>>>> Right, but an idle thread, waiting for a task that will never come 
>>>> since the only entry point for submitting tasks is not reachable 
>>>> (the pool), may be cleaned...
>>>
>>> cleaned? It can be interrupted if you know about it and find locate 
>>> it. But it will not be eligible for cleaning ala Cleaner as it will 
>>> always be strongly reachable.
>>
>> Ah I see what you meant before. Yes, tracking Thread object with a 
>> Cleaner does not have any sense. But tracking thread pool object with 
>> a Cleaner and cleaning (stopping) threads as a result makes sense...
>
> No, because live Threads will keep the thread pool strongly reachable.
>
> If you manage to structure things such that the Threads don't keep the 
> pool strongly reachable then you risk having the pool cleaned while 
> still actively in use.

Pool is actively in use when it is still reachable. Only in that case 
can new tasks be submitted. When it is not reachable any more, no new 
tasks can be submitted and it can be shutdown():

     /**
      * Initiates an orderly shutdown in which previously submitted
      * tasks are executed, but no new tasks will be accepted...

Regards, Peter