I'm not sure if this is the right approach, and synchronisation should probably
be added elsewhere to fix the underlying issue.

Trying to prevent a panic that was seen on container restore in th docker daemon:

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x5586c892a7a4]

    goroutine 420 [running]:
    github.com/docker/docker/vendor/github.com/containerd/fifo.(*fifo).Close(0x0, 0x0, 0x0)
            /go/src/github.com/docker/docker/vendor/github.com/containerd/fifo/fifo.go:208 +0x44
    github.com/docker/docker/vendor/github.com/containerd/containerd/cio.(*cio).Close(0xc000d06f60, 0x5586cb5654d0, 0xc000d8e9e8)
            /go/src/github.com/docker/docker/vendor/github.com/containerd/containerd/cio/io.go:203 +0x90
    github.com/docker/docker/libcontainerd/remote.(*client).Restore.func1(0xc0008bf820, 0xc0008a2040)
            /go/src/github.com/docker/docker/libcontainerd/remote/client.go:86 +0x5a
    github.com/docker/docker/libcontainerd/remote.(*client).Restore(0xc00098e5b0, 0x5586cb61c7c0, 0xc000052088, 0xc0011b6500, 0x40, 0xc0008bf810, 0x5586cb05cf00, 0xffffffffffffffff, 0x0, 0x0, ...)
            /go/src/github.com/docker/docker/libcontainerd/remote/client.go:107 +0x923
    github.com/docker/docker/daemon.(*Daemon).restore.func3(0xc00079d9e0, 0xc000a38230, 0xc00000c1e0, 0xc00079d9a8, 0xc000d84f00, 0xc000d84ed0, 0xc000d84ea0, 0xc00128a280)
            /go/src/github.com/docker/docker/daemon/daemon.go:351 +0x48a
    created by github.com/docker/docker/daemon.(*Daemon).restore
            /go/src/github.com/docker/docker/daemon/daemon.go:319 +0x4b3

If the fifo is nil, there's nothing to be done in Close(), so returning early
in that situation.

Signed-off-by: Sebastiaan van Stijn <[email protected]>

Signed-off-by: Phil Estes <[email protected]>

fifo.Close(): prevent possible panic if fifo is nil

Signed-off-by: Zou Nengren <[email protected]>

replace pkg/errors

The first test verifies that a Read() unblocks when we're closing the
reader.

The second test verifies that a Read() also unblocks when we're closing
the reader, even if a writer is pushing some bytes from the other end of
the pipe.

Signed-off-by: Samuel Ortiz <[email protected]>

fifo_test: Add 2 tests for closing after reading