Agree with Lucio and Bakul on each point. It is not something I need...just raising the observation that one could imagine "defer until even later" and it is an interesting thought experiment.
On Sat, Oct 7, 2017 at 1:59 AM, Bakul Shah <ba...@bitblocks.com> wrote: > > 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. > > -- 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.
