进入crypto / ssh包,stdoutpipe()io.Reader的缓冲区限制是多少

I'm writing a utility to execute commands on remote servers with the crypto/ssh package. I'm currently reading from the session.stdoutpipe() io.Reader in to a bytes.Buffer which I can format and print out after the session is complete.

The documentation states:

StdoutPipe func() (io.Reader, error) StdoutPipe returns a pipe that will be connected to the remote command's standard output when the command starts. There is a fixed amount of buffering that is shared between stdout and stderr streams. If the StdoutPipe reader is not serviced fast enough it may eventually cause the remote command to block.

I haven't had any issues so far with my testing, but it got me curious to know what is the fixed amount. I've successfully streamed text up to 6.5mb without reading the pipe Reader until the command has finished.

Does anyone know what the fixed amount is, or when the command will start to block? I can't find it in the source.

展开翻译

译文

我正在编写一个实用程序,以使用crypto / ssh软件包在远程服务器上执行命令。 我目前正在从session.stdoutpipe()io.Reader中读取一个bytes.Buffer,我可以在会话完成后对其进行格式化和打印。 </ p>

文档说明:</ p>


StdoutPipe func()(io.Reader,错误)
StdoutPipe返回一个管道,该管道将 命令启动时将其连接到远程命令的标准输出。 在stdout和stderr流之间共享固定数量的缓冲</ strong>。 如果StdoutPipe阅读器的维修速度不够快,则最终可能导致远程命令被阻止。</ p>
</ blockquote>

到目前为止,我的测试没有任何问题,但是 我很想知道固定金额是多少。 在命令完成之前,我已经成功读取了6.5mb的文本,而没有读取Pipe Reader。 </ p>

有人知道固定金额是多少,或者什么时候该命令将开始阻塞? 我在源代码中找不到它。</ p>
</ div>

1个回答

It is not in the Go source because it's OS dependent.

Applications should not rely on a particular capacity: an application should be designed so that a reading process consumes data as soon as it is available, so that a writing process does not remain blocked.

For example, on Linux:

$ man pipe

PIPE(2)                    Linux Programmer's Manual                   PIPE(2)

NAME
       pipe, pipe2 - create pipe

Pipe capacity

       A pipe has a limited capacity.  If the pipe is full, then a write(2)
       will block or fail, depending on whether the O_NONBLOCK flag is set
       (see below).  Different implementations have different limits for the
       pipe capacity.  Applications should not rely on a particular
       capacity: an application should be designed so that a reading process
       consumes data as soon as it is available, so that a writing process
       does not remain blocked.

       In Linux versions before 2.6.11, the capacity of a pipe was the same
       as the system page size (e.g., 4096 bytes on i386).  Since Linux
       2.6.11, the pipe capacity is 16 pages (i.e., 65,536 bytes in a system
       with a page size of 4096 bytes).  Since Linux 2.6.35, the default
       pipe capacity is 16 pages, but the capacity can be queried and set
       using the fcntl(2) F_GETPIPE_SZ and F_SETPIPE_SZ operations.  See
       fcntl(2) for more information.

展开翻译

译文



它不在Go源代码中,因为它取决于操作系统。 </ p>

应用程序不应依赖于特定的容量:应设计应用程序,以使读取过程在有可用数据时就立即消耗数据,从而不会阻止写入过程。< / p>

例如,在Linux上:</ p>


  $ man pipe 

PIPE(2)Linux程序员手册PIPE( 2)

NAME
管道,pipe2-创建管道

管道容量

管道的容量有限。 如果管道已满,则write(2)
将阻塞或失败,具体取决于是否设置了O_NONBLOCK标志
(请参见下文)。 不同的实现对管道容量有不同的限制。 应用程序不应该依赖于特定的容量
:应设计应用程序,以使读取过程
在可用时立即消耗数据,从而不会阻止写入过程。

在Linux中 在2.6.11之前的版本中,管道的容量与系统页面大小相同(例如,在i386上为4096字节)。 从Linux
2.6.11开始,管道容量为16页(即,系统中的65,536字节
,页面大小为4096字节)。 从Linux 2.6.35开始,默认的
管道容量为16页,但是可以使用fcntl(2)F_GETPIPE_SZ和F_SETPIPE_SZ操作查询和设置容量。 有关更多信息,请参见
fcntl(2)。
</ code> </ pre>
</ blockquote>
</ div>

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问