------- Comment #6 from  2009-04-19 20:02 -------
(In reply to comment #2)
> I agree that making the finalizers more deterministic is a good idea.
> As discussed in the NG I see two problems:
> 1) the use of finalizers for any non memory related resource is dangerous and
> should be avoided if possible. This because GC collections happens when the
> memory is constrained, not when the resource is constrained, and so one might
> unwillingly exhaust it. Thus making people use finalizers more and rely on the
> GC is not necessarily a good idea.

Agree, but finalizers exists, so I think the they should have the best support

> 2) There is a problem with daemon threads, threads that offer a service of
> listen for events. It is not always good/easy to stop them, and you risk
> strange errors. And no not using the GC in them is not a good option for them.

The problem is the whole runtime is shutdown. Daemon threads cannot allocate
new memory, for example, because the GC is terminated. So providing any kind of
guarantees for those threads seems to be almost impossible. I see those threads
very similar to calling C functions. You are going outside D support, and thus
you should have extra care and avoid using D "services" on them. As I said in
the NG discussion, I think for those rare cases were you have daemon threads
that are careful enough not to allocate new memory once the GC is terminated
but still use GC memory, a function can be provided to tell the GC not to call
finalizers for still referenced objects. But I don't think this should be the


Reply via email to