There are a bunch of examples of where they are *useful* (some in this thread). It's just, that you can not *rely* on them for correctness. If you are setting a finalizer, because something needs to happen before some value gets GCed/falls out of scope, you are doing it wrong, don't do it. If you are adhering to that and you *still* want to set a finalizer, it's probably useful. Go ahead.
On Sat, Jan 28, 2017 at 10:35 PM, John Souvestre <j...@souvestre.com> wrote: > > If you find a piece of code that uses a finaliser for the correct > operation of that program, that code is broken. > > Does that include using a finalizer with CGO code? From what I read, that > seems to be where they are most often used. > If it relies on them for correctness; yes. Most cases probably don't, they use it to tie the lifetime of some C-allocated memory to the lifetime of some go value encapsulating it. (You should still keep in mind, that someone else might very well also set a finalizer on some value you are giving to them, overriding yours. This is AFAIK not trivial to resolve, though.) > > > https://groups.google.com/forum/#!topic/golang-dev/DMiUkpS1uyQ > > John > > John Souvestre - New Orleans LA > > -- > 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. > -- 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.
