proposal: advise using SetFinalizer to detect resource leaks

88 views
Skip to first unread message

Mateusz Czapliński

unread,
Apr 5, 2018, 7:43:35 AM4/5/18
to golang-nuts
Based on a recent discussion on reddit, and a reply by BowsersaurusRex:

    "In C# I'll often use finalizers to track bugs in which an object was GC'd but Close() was never called."

I submitted the following proposal:

    https://golang.org/issue/24696

I'd love to see a solution which would not require adding to package runtime, but as of now I don't see how it could be possible — esp. if stdlib packages were to use it.

I'm curious what are your thoughts on whether this would be a good idea? Do you see some problems with that? Do you think it could be done outside standard library?

/Mateusz.

Axel Wagner

unread,
Apr 5, 2018, 7:55:47 AM4/5/18
to Mateusz Czapliński, golang-nuts
What would the runtime.Leaks channel do with the received errors? Why can't you just do the same thing from the finalizer itself?

--
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.

Mateusz Czaplinski

unread,
Apr 5, 2018, 7:59:25 AM4/5/18
to Axel Wagner, golang-nuts
Reading from it and handling the errors is left to user. There are many possible ways to handle it, so it's hard to guess in the finalizer what user wants:
  a) print them on stderr
  b) push them to some logging infrastructure
  c) just plain ignore them (default behavior)
User may not want or expect to have stderr trashed by some messages from libraries. Passing the errors through a common channel can help opt-in to the feature.

Axel Wagner

unread,
Apr 5, 2018, 8:06:47 AM4/5/18
to Mateusz Czaplinski, golang-nuts
On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski <czap...@gmail.com> wrote:
Reading from it and handling the errors is left to user.

Then why would this need to live in the stdlib? For example here is a quick and dirty implementation that allows the same functionality, without having to modify the stdlib:
This could be provided as a normal package and people can use it to augment any io.Closer (and, really, by extension anything) with this functionality.

Axel Wagner

unread,
Apr 5, 2018, 8:14:34 AM4/5/18
to Mateusz Czaplinski, golang-nuts
Of course this happens when you don't test your code ^^ Here is a version without compilation errors and with a quick demo: https://play.golang.org/p/ykO4igrC0b1

Mateusz Czaplinski

unread,
Apr 5, 2018, 9:12:40 AM4/5/18
to Axel Wagner, golang-nuts
I replied on the issue; in short, if the proposal gets dismissed, I'll take my chances at creating a third-party package with some super simple API, and then try advertising it here, on reddit, and maybe to other packages.
Reply all
Reply to author
Forward
0 new messages