Open muroj opened 4 days ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.
Hello!
You are correct that SDK clients are goroutine safe. However, Pager[T]
and Poller[T]
types returned from SDK methods are not. In your example, the following is not goroutine safe.
go func() {
blobs, err = blobPgr.NextPage(ctx)
handleError(err)
result <- struct{}{}
}()
Here, it's possible for multiple goroutines to call NextPage()
on the same blobPgr
instance which is not goroutine safe.
Please ping back if you have further questions.
Hi @muroj. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.
It appears this wasn't doc'ed. I've added doc comments about this in https://github.com/Azure/azure-sdk-for-go/pull/23679
Bug Report
Environment Info
github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/container
github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.4.1
go version go1.23.2 darwin/arm64
My program is detecting a data race while enumerating containers and blobs in parallel. Here is a minimal snippet demonstrating my approach.
Running this program results in the following data race, which occurs in the Blob Pager.
I am new to go routines, contexts, and channels, so I wouldn't be surprised if my code is buggy. Regardless, I'd like confirmation on whether the azure go SDK is thread safe. In particular, is it safe to share the clients between go routines? This go sdk design doc implies that clients should be threadsafe, but is that the case? The .NET SDK doc explicitly mentions thread safety, but the go SDK doc does not.