2015-12-03 10:19
浏览 48


I have a function which returns the Reader end of an io.Pipe and kicks off a go-routine which writes data to the Writer end of it, and then closes the pipe.

func GetPipeReader() io.ReadCloser {
    r, w := io.Pipe()
    go func() {
        _, err := io.CopyN(w, SomeReaderOfSize(N), N)
    return r

func main() {
    var buf bytes.Buffer
    io.Copy(&buf, GetPipeReader())
    println("got", buf.Len(), "bytes")


This seems to always work in my testing, in that I get all the data I wrote. But the API docs are a bit worrying to me:

func Pipe() (*PipeReader, *PipeWriter)

Pipe creates a synchronous in-memory pipe. [...] Reads on one end are matched with writes on the other, [...] there is no internal buffering.

func (w *PipeWriter) CloseWithError(err error) error

CloseWithError closes the writer; subsequent reads from the read half of the pipe will return no bytes and the error err, or EOF if err is nil.

What I want to know is, what are the possible race conditions here? Is is plausible that my go-routine will write a bunch of data and then close the pipe before I can read it all?

Do I need to use a channel for some signalling on when to close? What can go wrong, basically.

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • doutuo2829 2015-12-03 13:07

    No, there are no race conditions. As the documentation mentions, reads on one end are matched with writes on the other. So, when CloseWithError() is reached, it means every Write has successfully completed and been matched with a corresponding Read - so the other end must have read everything there was to read.

    解决 无用
    打赏 举报

相关推荐 更多相似问题