RFC: add ability to delete a finalizer for an object

[timholy]

I've encountered a situation where I want to define a finalizer to do some cleanup in case of error while constructing a file---the finalizer frees some resources and closes the file. However, when everything succeeds, I'd like to immediately close the file so I can pass it to an external program, which will then assume control. With the finalizer, I can't control when that happens without an explicit gc(), which I suspect is not the best choice (?). Consequently, I'd like to remove the finalizer for that object and do the cleanup manually, at the time I want.

This code may get close, but I'm concerned about the to_finalize array and any gc subtleties I may have missed. Hence the RFC.

If an explicit gc() is in fact the better way to go, just let me know and close without merging.

[JeffBezanson]

Calling gc() is definitely not the way to go. Maybe a better interface is a finalize function that calls an object's finalizer early? Currently calling finalizer(x,f) multiple times will add multiple finalizers for an object.

[StefanKarpinski]

What about exposing the finalizers table as an ObjectIdDict that can be programmatically manipulated?

[JeffBezanson]

I suppose that is something we, as adults, can consent to. What should it be called? ___finalizers___ ? :)

[StefanKarpinski]

Hahaha. Underscore-oriented for the win. No, I was thinking FINALIZERS. We might want to have a module that holds these kinds of system globals that are rarely needed but need to live somewhere. Module Sys maybe? Sys.VERSION, Sys.FINALIZERS, etc.? Too module-happy?

[JeffBezanson]

We do probably need a further subdivision of some stuff currently in Base. First, there are some things like the ErrorException type that the runtime expects to be defined, and will cause a crash otherwise. That is a very different kind of thing than a "library function". Then there are some other things that are exposed features of the runtime system, like gc and FINALIZERS. So we should add Sys I would say. Sys.VERSION is a problem because constructing a version object depends on a large portion of the Base library. As in #723, this involves asking what the scope of Base is --- what should it be possible to do without it, if anything?

[timholy]

I should point out that #1288 appears to spring from the same well. When that gets resolved, much of the motivation for this issue may go away.

[timholy]

This immediate need is satisfied very nicely by try...finally, and it's a cleaner and more general solution.

While I can imagine this issue might come up again in other contexts, I think it's better to wait for a compelling example. Hence, I'm closing this.