我正在编写一个针对Go的Jupyter内核,在执行Go代码之前,我创建了一个名为side named pipe(
我的内核创建了此命名管道,然后在新的goroutine中打开它进行读取,并相应地轮询输入。现在,打开命名管道进行读取是一种阻塞操作 (它会等待直到另一侧打开)。
但有些程序不想使用此机制,也永远不会打开命名管道的另一侧。当发生这种情况时,我的goroutine将出现泄漏,并且它将永远在打开的命名管道上等待 -- 即使我将其删除。
代码看起来大致如下(省略了错误处理):
syscall.Mkfifo
)的机制,以允许发布html、图像等内容。我的内核创建了此命名管道,然后在新的goroutine中打开它进行读取,并相应地轮询输入。现在,打开命名管道进行读取是一种阻塞操作 (它会等待直到另一侧打开)。
但有些程序不想使用此机制,也永远不会打开命名管道的另一侧。当发生这种情况时,我的goroutine将出现泄漏,并且它将永远在打开的命名管道上等待 -- 即使我将其删除。
代码看起来大致如下(省略了错误处理):
...
syscall.Mkfifo(pipePath, 0600)
go func() {
pipeReader, _ := os.Open(pipePath)
go poll(pipeReader) // Reads and process each entry until pipeReader is closed.
<-doneChan
pipeReader.Close()
}
go func() {
<-doneChan
os.Remove(pipePath)
}
doneChan
会在我启动的程序执行结束时关闭。
问题在于,即使 os.Remove(pipePath)
正确执行,如果另一端没有打开,os.Open(pipePath)
永远不会返回。
有没有一种方法可以强制中断 os.Open(pipePath)
,或者达到相同的效果的另一种方法?
提前感谢!!
os.OpenFile
没有记录这个选项(也没有定义O_NONBLOCK
)。在 fifo 的文档中仔细阅读后,他们确实提到了非阻塞打开读取将立即成功返回(我很惊讶,我以为它会立即失败),所以我们得到了一个*os.File
。但根据这篇博客文章,从这个文件读取将返回 EAGAIN 而不是阻塞。我必须试一下... - Jan