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
