First...
go func() {
f()
go g()
}()
is tremendously different than:
go func() {
go g()
f()
}()
and neither is equivalent to :
go func() {
f()
g()
} ()
...and on the order of evaluation and visibility and weak memory coherence
guarantees and all manner of Go "non-promises" those are a reflection of
underlying hardware reality, which does not look to get any more rich in
various concurrency promises.
On Tue, Oct 10, 2017 at 4:38 PM, Juliusz Chroboczek <j...@irif.fr> wrote:
> > 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.
>
--
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.
