On Sat, Jan 28, 2017 at 10:22 PM John Souvestre <j...@souvestre.com> wrote:
> > If finalizers were indeed totally useless, it would obviously be totally > useless to implement support for them. > > If someone described a few cases where finalizers were useful perhaps it > would help understand them. > > The common case usually has to do with some kind of finite resource of which you have "enough", but as the program runs, you'd like to eventually make sure that you don't leak said resource and give it back to the kernel so it can be reused. Another common case is when you have some kind of registry to which you associate properties of objects in the system. If the object somehow gets collected, you'd like the entry to be removed from the registry eventually. Keeping it there for a while isn't a problem, but keeping it for the rest of the programs lifetime is. it is much like garbage in a GC: as long as you eventually get to the garbage and sweep it to the free-list, you are golden. Finalizers are a special case of a more general "ephemeron" construction, which can avoid some of the common trouble finalizers tend to have. There are some subtle interactions in which a (strong) reference keeps an object alive in the GC and thus creates a leak anyway. The reason finalizers (ephemerons) are useful is that library authors can present somewhat simpler APIs in some cases. Rather than you having to do some cleaning, the library makes sure that it handles it itself, though with added resource pressure as a result. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
