On Tue, 10 Oct 2017 09:27:52 -0400 Shawn Milochik <shawn.m...@gmail.com> wrote:
Shawn Milochik writes:
> 
> On Tue, Oct 10, 2017 at 9:13 AM, Scott Cotton <w...@iri-labs.com> wrote:
> 
> > Hi all,
> >
> > 1. "defer go"   extend defers to work on goroutine exit with mechanism
> > just like defer, but if we say "defer go f()"
> > instead of "defer f()" then we run on goroutine exit.  Very big gains for
> > scaling here IMHO.
> >
> >
> You can already "defer go": defer func() { go otherFunc() }()

Ignore the exact syntax but the idea is to delay some defer() execution
until goroutine exit. For example,

        func foo() {
                f, err := os.Open("/etc/passwd")
                if err != nil {
                        // complain and eturn
                }
                defer-until-goroutine-exit f.Close()
                .....
        }


        go func() {
                ...
                foo()
                ....
                // this is where f.Close() from foo() will be executed
        }

See my email to this group on Oct 7 with the subject "are all
running goroutines killed when main ends?"

[
I originall thought of this to ensure that some required clean
up action is executed no matter how a program dies (as long as
the OS doesn't kill it without giving it a chance to do such
as cleanup. In C for example, you can register a signal
handler for SIGQUIT etc. and when the program exits, functions
registered via atexit() get run.

In the past some people have expressed a desire to have
something like atexit() in Go.  But in a concurrent program it
makes more sense (IMHO) to let each sequential thread do its
own final cleanup. But the runtime has to make this happen,
which is a new mechanism is needed. I suggested "defer go"
but the exact syntax is less important.

An alternative is to have each each "main" function of
have a recover() block where it does such cleanup. And
then each thread has to keep checking a global variable
that asks it to immediately terminate, at which point
it can panic(). This requires cooperation from each thread
(but you don't have any control over goroutines in some third
party package).

While useful, I don't know if this has *sufficient* utility in
the Go world.
]

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

Reply via email to