[Doc] Explain why goroutine sample is threadsafe

[xxgreg]

What are you really trying to do?

I'm learning how to use workflow.Go.

Reading the goroutine sample code I thought there was a race condition, as multiple concurrent goroutines are calling append on the same slice in the outer scope.

See: https://github.com/temporalio/samples-go/blob/main/goroutine/goroutine_workflow.go

i.e.

var results []string 
...
workflow.Go(ctx, func(gCtx workflow.Context) {
    ...
    results = append(results, result2)
})

It turns out that this isn't a race condition, as workflow.Go is different than a goroutine, so it's probably worth explaining this difference in the sample.

[xxgreg]

So according to this comment - this isn't a race condition.

https://community.temporal.io/t/is-workflow-go-safe-for-concurrency/6722

[Quinn-With-Two-Ns]

Yes this is thread safe as only one coroutine is ever run at a time. I see no harm in adding an extra comment explaining why

[Quinn-With-Two-Ns]

I updated the github issue to reflect the actual issue

[ioannist]

I was actually wondering the same thing. It seems that workflow "goroutines" are not really goroutines in the Go sense.

It should be more clear how workflow goroutines differ from actual goroutines.

I was also wondering what are the advantages/disadvantages of branch or splitmerge-selector vs. goroutine examples. They seem to be serving very similar use cases, very differently. It's probably worth it to cross-reference and compare the two in their respective descriptions.