Re: [go-nuts] Are all running goroutines killed when main ends?

[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

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

Re: [go-nuts] Are all running goroutines killed when main ends?

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

On Sat, Oct 7, 2017 at 1:59 AM, Bakul Shah  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 
> 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.

Re: [go-nuts] Are all running goroutines killed when main ends?

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

> On Oct 6, 2017, at 6:48 AM, Michael Jones  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 
>  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.

Re: [go-nuts] Are all running goroutines killed when main ends?

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

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

Re: [go-nuts] Are all running goroutines killed when main ends?

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

Re: [go-nuts] Are all running goroutines killed when main ends?

[Mikhail Mazurskiy]

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.

Re: [go-nuts] Are all running goroutines killed when main ends?

[go-question]

Thanks for clearing that up!


On Thursday, October 5, 2017 at 9:52:30 PM UTC-7, Dave Cheney wrote:
>
> 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. 

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

RE: [go-nuts] Are all running goroutines killed when main ends?

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

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

RE: [go-nuts] Are all running goroutines killed when main ends?

[John Souvestre]

Any easy way to make their defers run?

John

John Souvestre - New Orleans LA


-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Dave Cheney
Sent: 2017 October 05, Thu 23:36
To: golang-nuts
Subject: [go-nuts] Are all running goroutines killed when main ends?

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

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

Re: [go-nuts] Are all running goroutines killed when main ends?

[Ian Lance Taylor]

On Thu, Oct 5, 2017 at 8:09 PM, go-question
 wrote:
>
> When a program's main ends, will all running goroutines that were created by
> the program also be stopped and cleaned up?

Yes.

Ian

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