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.
