Are all running goroutines killed when main ends?

[go-question]

When a program's main ends, will all running goroutines that were created by the program also be stopped and cleaned up?

[Ian Lance Taylor]

Yes.

Ian

[Dave Cheney]

Yes, they will be stopped. However they will be stopped abruptly, no defers will run.

[John Souvestre]

Any easy way to make their defers run?

John

John Souvestre - New Orleans LA

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

[Dave Cheney]

The only answer I have is to ask those goroutines to exit, the wait for them to exit. Context is part of this, combined with a waitgroup to track goroutines in flight.

[go-question]

Thanks for clearing that up!

[Mikhail Mazurskiy]

I wrote a library to help with this https://github.com/ash2k/stager

[Michael Jones]

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....@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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones
michae...@gmail.com

[Lucio]

On Friday, 6 October 2017 15:49:18 UTC+2, Michael Jones wrote:

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.

One ought to be able to at least model that with the existing Go features, demonstrate its usefulness, which I don't question, Context was addressed that way. I'm still getting my head around context and I think (and hope) it will be much simpler to grasp once it becomes a language feature, but I'm happy it was modelled the way it was.

Lucio.

[Bakul Shah]

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"!

> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

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

[Michael Jones]

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.

> 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 T. Jones
> michae...@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+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[David Collier-Brown]

On Friday, October 6, 2017 at 9:49:18 AM UTC-4, Michael Jones wrote:

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.

Hmmn: a "will" library might create a list of steps to be done by a call to defer will.executor() in main().

I'd be interested in how many variables have to moved to the heap from the stack in such cases.

--dave