`os.OpenFile` with O_RDONLY hangs on named pipe with no writers

I am writing a daemon that is supposed to receive notifications from ephemeral CLI commands and have chosen to do so through a unix named pipe. I have written a short package that on the one hand spawns a separate goroutine to read from the node and send the received notifications down a channel (playground w/ unit test):

type Writer struct {
	f *os.File
}

func NewWriter(ipc string) (*Writer, error) {
	f, err := os.OpenFile(ipc, os.O_WRONLY, 0600)

	if err != nil {
		return nil, fmt.Errorf("writer: open file: %w", err)
	}

	return &Writer{f: f}, nil
}

func (w *Writer) WriteString(str string) (int, error) {
	return w.f.WriteString(fmt.Sprint(str, "\n"))

}

func (w *Writer) Close() error {
	return w.f.Close()
}

type Reader struct {
	f    *os.File
	rmFn func() error
	quit chan struct{}
	done *sync.WaitGroup
}

func NewReader(ipc string) (*Reader, error) {
	err := syscall.Mkfifo(ipc, 0640)
	if err != nil {
		return nil, fmt.Errorf("reader: create fifo: %w", err)
	}

	f, err := os.OpenFile(ipc, os.O_RDONLY, 0640)
	if err != nil {
		return nil, fmt.Errorf("reader: open fifo: %w", err)
	}
	return &Reader{
		f:    f,
		quit: make(chan struct{}),
		done: &sync.WaitGroup{},
		rmFn: func() error {
			return os.Remove(ipc)
		},
	}, nil
}

func (r *Reader) PollRead() <-chan string {
	reader := bufio.NewReader(r.f)
	out := make(chan string)
	r.done.Add(1)
	go func() {
		defer r.done.Done()
		for {
			line, err := reader.ReadBytes('\n')
			if err != nil {
				fmt.Printf("error reading from named pipe: %v\n", err)
				return
			}

			nline := string(line)
			nline = strings.TrimRight(nline, "\n")
			select {
			case out <- nline:
			case <-r.quit:
				close(out)
				return
			}
		}
	}()

	return out
}

func (r *Reader) Close() error {
	close(r.quit)
	r.done.Wait()
	err := r.f.Close()
	if err != nil {
		return fmt.Errorf("error closing named pipe: %v", err)
	}

	err = r.rmFn()
	if err != nil {
		return fmt.Errorf("error removing named pipe: %v", err)
	}
	return nil
}

This does appear to be working, however it suffers from the peculiar behavior that no readers can open the file until any writers open the file, which appears to be the reverse behavior according to other things I've read on the topic; the usual complaint is that the writers are hanging because there aren't any readers, however, here a reader cannot be instantiated in the first place.

This is the default behavior as documented in the POSIX system interfaces:

> O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: If
> O_NONBLOCK is set, an open() for reading-only shall return without
> delay. An open() for writing-only shall return an error if no process
> currently has the file open for reading.
>
> If O_NONBLOCK is clear, an open() for reading-only shall block the
> calling thread until a thread opens the file for writing. An open()
> for writing-only shall block the calling thread until a thread opens
> the file for reading.
>
> When opening a block special or character special file that supports
> non-blocking opens:
>
> If O_NONBLOCK is set, the open() function shall return without
> blocking for the device to be ready or available. Subsequent behavior
> of the device is device-specific.
>
> If O_NONBLOCK is clear, the open() function shall block the calling
l> thread until the device is ready or available before returning.
>
> Otherwise, the O_NONBLOCK flag shall not cause an error, but it is
> unspecified whether the file status flags will include the O_NONBLOCK
> flag.

The solution is, therefore, to add the syscall.O_NONBLOCK flag to the OpenFile call:

    f, err := os.OpenFile(ipc, os.O_RDONLY|syscall.O_NONBLOCK, 0640)

EDIT: As discussed in the comments, this solution is not portable to darwin environments. A more portable solution would be to open the file with O_RDWR on the reader side.