Provide cancellation and progress channels in WaitForOperationStatus about azure-sdk-for-go HOT 10 CLOSED

@paulmey I'm thinking about this and we can do something like for cancellation: http://play.golang.org/p/TgIwmKxsad Please review.

We can modify WaitAsyncOperation(opID) to take an extra cancellation chan. User is allowed to pass nil to chan (user doesn't want to use cancellation). Or if they want to use it, they must close the cancellation chan.

The return value from WaitAsyncOperation is chan error.

Scenario-1: User just waits forever

err := <-WaitAsyncOperation(opID, nil)

(in this case no cancellation would happen and err==nil would mean op was successful).

Scenario-2: User might want to use cancellation

cancelCh := make(chan struct{}) /// user might close(cancelCh) in some other goroutine...
err, cancelled := <-WaitAsyncOperation(opID, cancelCh)

(in this case err==nil might mean (a) wait cancelled (b) op was successful. That's where cancelled comes in, if it's true, means (a) otherwise means (b).)

from azure-sdk-for-go.

@svanharmelen I appreciate your input here as well.

from azure-sdk-for-go.

@ahmetalpbalkan overall approach sounds good to me. Do have 2 questions/remarks...

1. Do I read/understand correctly that the return value of WaitAsyncOperation would be a channel? I would not do that and I also don't see why you would want to do that in this case? Why not just return an error and a bool? Seems much more appropriate and clear in relation to what your actually are trying to do here. Also wondering, while looking at the playground example, if ok in err, ok := <-errCh will ever be anything else than nil in this example? It seems that even if it's cancelled it will still be nil.
2. Just for clarity and/or in case you are going to add it to the docs/comments... You write: "Or if they want to use it, they must close the cancellation chan", but of course sending a message to the channel will work just as well.

from azure-sdk-for-go.

@svanharmelen

1. You're right I'm overengineering here I guess. We can still return error from the method and yet can still support cancellation.
2. Closing channel is smarter, because that way multiple goroutines can wait on the same ch, and all will be closed, however if you do <-ch only one will be closed and others will be locked forever.

from azure-sdk-for-go.

@svanharmelen check this, much simpler: http://play.golang.org/p/FxzU8d7Xbs

from azure-sdk-for-go.

That last one is pretty cool. I'm all for it.

from azure-sdk-for-go.

Yes, that looks a lot cleaner to me as well...

from azure-sdk-for-go.

Sent PR for this at #137.

from azure-sdk-for-go.

Hi,

Have you considered go's context for cancellation? It looks really easy to use :)

from azure-sdk-for-go.

@mvanotti quite honestly we didn't. :-) Although I doubt use case within this library would go beyond a simple cancellation channel, if that is becoming the standard way between Go libraries and programs to operate on cancellation and pipelines, we'd love to use that as well.

Feel free to open up a proposal issue, or better– prototype and send a pull request. :-)

from azure-sdk-for-go.