Asynchronous APIs

[ansiwen]

As I was looking in the asynchronous APIs, I realized that there are subtle differences in the need for async. Roughly speaking, there are at least two "features" of async APIs:

1. non-blocking, concurrency
2. receiving multiple events

In go, since there are goroutines, channels and anonymous functions, there is not much use for feature 1. For example, an async write function is not needed, since you can simply use the normal write function in a goroutine. If you wanna know, then the writing is done, you can simply use a waitgroup, channel or even a bool (if you wanna poll), that is set in the goroutine after the write returns.

So I think we should focus on the feature 2, receiving multiple events from a single asynchronous function (in contrast to a single "done" event, which is equivalent of a synchronous-function-returned event, and therefore not necessary in go, see feature 1). That makes sense for long running reads for example, that return the result in chunks. Or subscription of any other repeating event, like for watchers. When we do that, we should use the go-idiomatic way to receive repeating events: channels.

Thoughts?

[phlogistonjohn]

Interesting. I think your first point is reasonable modulo listening to users and if there's a big demand for 1 at some point we can do it. But I fully agree that there's no big driver for that now. As for item 2, I think I need a few examples... perhaps some go-ish pseudocode?

[ansiwen]

see #634