FAQ
Since Go is garbage collected, we can create pointers to things and pass
them around without having to worry about them not being cleaned up. It's
great! We also have easy access to C libraries, which is also great.

Is there any way for a C binding to detect when a variable is about to be
garbage collected so that it can run the required cleanup operations
without the library user having to worry about it? In fewer words, I'm
looking for a way to implement an automatic deconstructor in Go. Is it
possible?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Paul Borman at Jul 7, 2015 at 9:36 pm
    Maybe runtime.SetFinalizer?

    http://golang.org/pkg/runtime/#SetFinalizer
    On Tue, Jul 7, 2015 at 2:26 PM, Tyler Compton wrote:

    Since Go is garbage collected, we can create pointers to things and pass
    them around without having to worry about them not being cleaned up. It's
    great! We also have easy access to C libraries, which is also great.

    Is there any way for a C binding to detect when a variable is about to be
    garbage collected so that it can run the required cleanup operations
    without the library user having to worry about it? In fewer words, I'm
    looking for a way to implement an automatic deconstructor in Go. Is it
    possible?

    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Axel Wagner at Jul 7, 2015 at 10:16 pm
    There is some worthwile discussion, whether SetFinalizer is right for
    this. One of the reasons is, that you can only ever have one Finalizer,
    so if someone uses SetFinalizer themselves with your library, this will
    lead to Resource Leaks.

    For that reason, I would prefer making your resource an io.Closer. It is
    common understanding, that you need to call Close on a Closer, when you
    are done with it. If the user of your library then wants to live
    worry-free, they can SetFinalizer themselves to its Close method. So
    something like this (untested):
    http://play.golang.org/p/X_YA2xPpRd

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tyler Compton at Jul 7, 2015 at 10:50 pm
    That's good to know. To me though, having an object with a Close method is
    only marginally better than it having a Destroy or Free method. It follows
    Go convention more closely, but it doesn't really make the library any more
    easy to use. It is true that the user could inadvertently circumvent proper
    memory management, though.

    Why not have the best of both worlds and have the library use SetFinalizer
    on a public Close method by default, and mention this behavior in the
    documentation. So long as the Close method has a way of checking whether or
    not memory has already been freed, the user could set their own
    SetFinalizer to Close, Close manually, or not even touch the issue and
    memory will be freed correctly regardless.
    On Tuesday, July 7, 2015 at 3:17:04 PM UTC-7, Axel Wagner wrote:

    There is some worthwile discussion, whether SetFinalizer is right for m,
    this. One of the reasons is, that you can only ever have one Finalizer,
    so if someone uses SetFinalizer themselves with your library, this will
    lead to Resource Leaks.

    For that reason, I would prefer making your resource an io.Closer. It is
    common understanding, that you need to call Close on a Closer, when you
    are done with it. If the user of your library then wants to live
    worry-free, they can SetFinalizer themselves to its Close method. So
    something like this (untested):
    http://play.golang.org/p/X_YA2xPpRd
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tyler Compton at Jul 7, 2015 at 10:52 pm

    That being said, I took a look at the docs and saw this disheartening line:

    There is no guarantee that finalizers will run before a program exits, so
    typically they are useful only for releasing non-memory resources
    associated with an object during a long-running program

    So this isn't really a reliable solution after all, unfortunately.
    On Tuesday, July 7, 2015 at 3:17:04 PM UTC-7, Axel Wagner wrote:

    There is some worthwile discussion, whether SetFinalizer is right for
    this. One of the reasons is, that you can only ever have one Finalizer,
    so if someone uses SetFinalizer themselves with your library, this will
    lead to Resource Leaks.

    For that reason, I would prefer making your resource an io.Closer. It is
    common understanding, that you need to call Close on a Closer, when you
    are done with it. If the user of your library then wants to live
    worry-free, they can SetFinalizer themselves to its Close method. So
    something like this (untested):
    http://play.golang.org/p/X_YA2xPpRd
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Axel Wagner at Jul 8, 2015 at 7:16 am

    Tyler Compton writes:
    That being said, I took a look at the docs and saw this disheartening line:
    There is no guarantee that finalizers will run before a program exits, so
    typically they are useful only for releasing non-memory resources
    associated with an object during a long-running program

    So this isn't really a reliable solution after all, unfortunately.
    Well, if that is important, you really should add a Close-method to
    release all resources (and document what happens, if they don't get
    released). There are good reasons not to GC everything before a program
    exits, so go won't grow an automatism here, that guarantees this for
    you. And I wouldn't worry about it being to cumbersome or hard to use:
    People don't complain about os.File or sql.DB or any other Closer in the
    stdlib, they will deal with yours :)

    BTW, if you still want to go with a Finalizer, just as a safeguard, there
    is a way around the problems I mentioned: Mimicing os.File, you can set
    the Finalizer on a private member of a returned struct, instead of the
    struct itself. Haven't thought of that yesterday :)

    Best,

    Axel

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Schaller at Jul 8, 2015 at 9:38 am
    The part of the SWIG documentation with regards to this problem might be
    also of interest to you. It can be found
    here: http://www.swig.org/Doc3.0/SWIGDocumentation.html#Go_class_memory

    IMHO whenever you can use defer then you should use it. defer can be used
    in more complex scenarios if you keep C resources function local. If you
    really need runtime.SetFinalizer then please read its documentation and
    make sure you've understood its caveats. The SWIG documentation includes
    all these topics. Furthermore, as its easy to miss in the
    runtime.SetFinalizer documentation, please note that a finalizer won't run
    if the object it relates to is in a cycle with another Go object.

    Last but not least, if you implement a Close method then make sure that you
    prevent double free under all circumstances (race conditions).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 7, '15 at 9:26p
activeJul 8, '15 at 9:38a
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase