Re: [PATCH]: natThread.cc: Destroy join sync objects in finalizer

[Hans Boehm <Hans dot Boehm at hp dot com>]

There is no guarantee on the order in which the finalizers are run.

(This would all work out if we let the collector do topologically
ordered finalization.  But that would violate at least the intent
of the Java spec.  But it's much easier to use correctly.)

In this case, is it possible to invoke the cleanup code from
a java.lang.Thread finalizer?  Is java.lang.Thread allowed to have
a finalizer?

Hans

On Sat, 11 Sep 2004, Bryce McKinlay wrote:

> Bryce McKinlay wrote:
>
> > Tom Tromey wrote:
> >
> >> Mohan> The GC finalizer finalize_native in natThread.cc should destroy
> >> Mohan> the join synchronization objects if the target platform supports
> >> Mohan> these destruction operations (which isn't the case for Linux and
> >> Mohan> -DLINUX_THREADS but is the case for Win32).
> >>
> >> This isn't a problem with your patch, but what happens if a user
> >> writes a subclass of Thread that has a finalize method which
> >> resurrects the Thread?  Won't we start referring to freed data in this
> >> code?
> >>
> >>
> > Does the GC run finalizers in the order that they are registered? If
> > so then we should be ok.
>
> Hmm. Or maybe not, if it runs them both at once.
>
> Bryce
>