026896ac4c
In all of the examples, its recommended to call `Wait()` before starting
a process/task.
Since `Wait()` is a blocking call, this means it must be called from a
goroutine like so:
```go
statusC := make(chan uint32)
go func() {
status, err := task.Wait(ctx)
if err != nil {
// handle async err
}
statusC <- status
}()
task.Start(ctx)
<-statusC
```
This means there is a race here where there is no guarentee when the
goroutine is going to be scheduled, and even a bit more since this
requires an RPC call to be made.
In addition, this code is very messy and a common pattern for any caller
using Wait+Start.
Instead, this changes `Wait()` to use an async model having `Wait()`
return a channel instead of the code itself.
This ensures that when `Wait()` returns that the client has a handle on
the event stream (already made the RPC request) before returning and
reduces any sort of race to how the stream is handled by grpc since we
can't guarentee that we have a goroutine running and blocked on
`Recv()`.
Making `Wait()` async also cleans up the code in the caller drastically:
```go
statusC, err := task.Wait(ctx)
if err != nil {
return err
}
task.Start(ctx)
status := <-statusC
if status.Err != nil {
return err
}
```
No more spinning up goroutines and more natural error
handling for the caller.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
|
||
|---|---|---|
| .. | ||
| _includes | ||
| _layouts | ||
| hooks | ||
| images | ||
| style | ||
| _config.yml | ||
| .dockerignore | ||
| .gitignore | ||
| client-opts.md | ||
| dockercon-summit.md | ||
| Dockerfile | ||
| getting-started.md | ||
| index.md | ||
| namespaces.md | ||
| ops.md | ||
| README.md | ||
Containerd website
The containerd website is built using Jekyll and published to Github pages.
In order to build and test locally:
docker run -it -v "$PWD":/usr/src/app -p "4000:4000" starefossen/github-pages
Then browser to localhost:4000 to see the rendered site. The site autorefreshes when you modify files locally.