If a process is killed by the kernel for some reason (or kill -9) none of these cleanup functions will run. The last will idea is meaningful only when the main() dies and doesn't care to wait for all the other goroutines to die a clean death. But in this case you are in essence passing a function (that needs the context of one thread) to another thread (main). This can't work and even if you make it work somehow, debugging it would be a nightmare. Just as a defer is cleanups to be run when a function exits and C's atexit() is cleanups to be run when a process exits, cleanups to be run when a goroutine exits is meaningful and can be run in the same context as the goroutine. Such cleanups can be used in normal code as well.
Implementation idea: the runtime must have something that uniquely identifies a goroutine. This "id" can be used as a key to store a chain of cleanup functions. Exiting a thread would run any such functions. You don't need the equivalent of C's atexit() function since on process exist (via main() terminating or OS.Exit()), the runtime finds all alive threads and cause them to run any cleanups before destroying them. Not having looked at the runtime I am not sure how painful this is but this has the benefit of not adding any cost when there is no goroutine level cleanup. As for syntax I am tempted to suggest "go defer"! > On Oct 6, 2017, at 6:48 AM, Michael Jones <michael.jo...@gmail.com> wrote: > > This line of reasoning suggests an idea to me. > > Defer has the grammatical notion of "i want to do this later, but eventually, > i don't want to forget to do it before i leave." > > Imagine the slightly stronger notion of a "will" as in a person's last will > and testament. Actions in your will are steps to be carried out in the event > of your death. Presumably if an action has already been done during your > lifetime, then that part of the will is mooted. > > Imagine a "will" statement in Go. Instead of Defer's chaining calls on the > local function's return, the Will would do that with a wrapper that would set > a bit saying "this has been done" but would also install a wrapper to the > call on a global list owned by the runtime, which would inspect the bits at > main's exit and call any functions that have not already been called. > > The function called at main's exit would be the 'executor' of the various > wills. > > On Fri, Oct 6, 2017 at 1:08 AM, Mikhail Mazurskiy > <mikhail.mazur...@gmail.com> wrote: > I wrote a library to help with this https://github.com/ash2k/stager > > -- > 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. > > > > -- > Michael T. Jones > michael.jo...@gmail.com > > -- > 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.
