Hi, yes, the thread should use try...finally to cleanup its resources explicitly. The method to cleanup and release resources should *not* be called finalize and should be idempotent. Finalization is needed as a last resort it should call the cleanup method (and nothing else). Not all resources are lexically scoped but encapsulating the resource in a class, naming the method close and implementing AutoCloseable are good conventions. As you probably know, calling the finalize method *does not* trigger the finalization process and so finalize could be called again. $02, Roger On 3/15/17 6:43 AM, Andrew Haley wrote:
On 15/03/17 10:21, Timo Kinnunen wrote:
If we are to come up with a good alternative to finalization, having to compare disparate things seems unavoidable. Comparing threads and Threads, suppose there’s a subclass of Thread which holds a native resource that’s not reachable from any other Thread and it has a finalize method. Let’s say this Thread’s resource is a handle to its own native thread and the finalize method calls CloseHandle on the handle and ExitThread to signal an A-OK exit code. The thread will not be removed from the system while the handle remains open. Could this Thread’s thread invoke its own finalize method once it’s done or would it have to wait for the Finalizer to call it instead, and if so, why? Isn't this a classic example of Finalizer abuse? A Thread's run() method could be enclosed in a try ... finally region which closes the handle. If, for some odd reason, that doesn't happen, then the Thread's finalizer is a last resort, but it shouldn't normally be needed. Whether it's safe for a native thread to invoke its Thread's finalize method depends on the OS-specific details of what CloseHandle does.
Andrew.