> 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.
If I read the language specification right, goroutines have no identity:
a goroutine is about doing something, and the something is not bound to
any particular context. For example, if you do
go func() {
f()
go g()
}()
this is completely equivalent to
go func() {
f()
g()
} ()
in the sense that there is no observable difference betwen the two, and
a Sufficiently Smart Compiler could in principle optimise the former
into the latter.
Is that an important property to have? Frankly, I don't know.
-- Juliusz
--
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.
