GC object finalization not guaranteed

Leandro Lucarella llucax at gmail.com
Sat Apr 18 14:59:11 PDT 2009


Fawzi Mohamed, el 18 de abril a las 23:43 me escribiste:
> >If thread_joinAll() is called before gc_term(), I can't see how a thread
> >could be still running when gc_term() is called. So, in terms of threads,
> >I don't see a problem here.
> 
> daemon theads are not joined

So, you can keep threads going on even when you have terminated the GC?
That's odd! I think that's an accident waiting to happen =)

Anyways, if you do have a thread live when the GC is terminate, a lot of
care have to be taken, I don't see why "do not use GC allocated memory" in
threads that live longer than the GC should not be added to the
limitations. It seems pretty reasonable.

> >About exceptions, I think it could be solved too. One option is to require
> >gc_term() to be "nonthrow" (I mean, for D1 and D2). I think the specs
> >doesn't say anything about destructors throwing exceptions. I think they
> >shouldn't but let's suppose they could. Since there is no way the use can
> >catch a destructor exception thrown in the GC (well, not in an useful way,
> >one could try/catch the new call or something but that doesn't work for
> >concurrent collectors that can sweep in a separate thread anyway, so
> >I think it's a bad idea), I guess it would be acceptable to:
> >a) Ignore the exception
> >b) Let the user provide a callback to handle that kind of exceptions
> 
> finalizer should not throw already now, if they do an exception is raised.

Ok, so then exceptions thrown by destructors are not a problem either.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
... los cuales son susceptibles a una creciente variedad de ataques previsibles,
tales como desbordamiento del tampón, falsificación de parámetros, ...
	-- Stealth - ISS LLC - Seguridad de IT



More information about the Digitalmars-d mailing list