php小编香蕉为您介绍一种特殊的操作方式，即使用带有 O_RDONLY 的 os.OpenFile 函数在没有编写器的命名管道上进行挂载。这种操作方式可以实现对命名管道的读取操作，让您能够在不使用编写器的情况下，轻松获取命名管道中的数据信息。这一技巧简单易懂，操作方便，是开发者们在处理命名管道时的绝佳选择。接下来，我们将为您详细介绍如何使用这种方法来实现命名管道的读取操作。
问题内容
我正在编写一个守护进程，它应该从临时 cli 命令接收通知，并选择通过 unix 命名管道来执行此操作。我编写了一个简短的包，一方面生成一个单独的 goroutine 以从节点读取并将收到的通知发送到通道（带有单元测试的游乐场）：
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
}
这似乎确实有效，但是它受到一种特殊行为的影响，即在任何编写者打开该文件之前，没有读者可以打开该文件，这似乎是根据我读过的有关该主题的其他内容来扭转行为；通常的抱怨是编写器挂起，因为没有任何读取器，但是，这里首先无法实例化读取器。
解决方法
这是 posix 系统接口中记录的默认行为>：
o_nonblock 当打开设置了 o_rdonly 或 o_wronly 的 fifo 时： 如果 o_nonblock 被设置，只读的 open() 将返回而不需要 延迟。如果没有进程，只写的 open() 将返回错误 当前已打开文件供读取。
如果 o_nonblock 被清除，则只读的 open() 将阻塞 调用线程，直到线程打开文件进行写入。一个开放的() 只写应阻塞调用线程，直到线程打开 供读取的文件。
打开支持的块特殊或字符特殊文件时 非阻塞打开：
如果设置了 o_nonblock，则 open() 函数将返回而不带 阻止设备准备就绪或可用。随后的行为 设备的属性是特定于设备的。
如果 o_nonblock 被清除，则 open() 函数将阻止调用 l> 线程直到设备准备好或可用才返回。
否则，o_nonblock 标志不会导致错误，但它是 未指定文件状态标志是否包含 o_nonblock 标志。
因此，解决方案是将 syscall.o_nonblock 标志添加到 openfile 调用中：
f, err := os.OpenFile(ipc, os.O_RDONLY|syscall.O_NONBLOCK, 0640)
编辑：正如评论中所讨论的，此解决方案不可移植到 darwin 环境。更便携的解决方案是在读取器端使用 o_rdwr 打开文件。
