在执行其他操作时非阻塞读取管道

Question

在将大量数据写入管道时 ，由于挂起了进程 ，因此，我需要实现一种方法，使父进程从子进程写入的管道中读取父进程，同时执行其他操作直到子进程完成。

更具体地说，父级正在通过HTTP向客户端返回响应。 响应由字符串<PING/>组成，在完成ping操作后由字符串<DONE/> ，其后是实际内容。 这样做是为了使连接保持活动状态，直到准备好实际响应为止。

我的问题：

1）我主要是在寻找一般反馈。 您发现此代码有任何问题吗？

2）我会实现非阻塞阅读的目标吗？ 特别是，一旦读取了所有当前可用的数据（但编写器仍在编写更多数据），我的代码就可以继续运行while ( my $line = <$pipe_reader>){吗？ 在关闭管道之后，在孩子终止之前，它能正常工作吗？

3） IO::Select的文档说add()带有IO::Handle对象。 我到处都看到IO::Handle ，但是我不知道如何确定以此方式创建的管道是否算作IO::Handle对象。 perl -e "pipe(my $r, my $w); print(ref($r))"给了我GLOB ...

4） select的Perl文档（我认为IO::Select基于该文档）警告

警告：除非POSIX允许，否则不要尝试将缓冲的I / O（例如read或readline ）与select ，即使仅在POSIX系统上也是如此。 您必须改为使用sysread 。

这是否意味着拥有$writer->write('<PING/>');是一个问题$writer->write('<PING/>'); 在同一个循环中？

Perl代码

pipe(my $pipe_reader, my $pipe_writer);
$pipe_writer->autoflush(1);

my $pid = fork;

if ( $pid ) {

    # parent
    close $pipe_writer;

    $s = IO::Select->new();
    $s->add($pipe_reader);

    my $response  = "";
    my $startTime = time;
    my $interval  = 25;
    my $pings     = 0;

    while ( waitpid(-1, WNOHANG) <= 0 ) {

        if ( time > $startTime + ($interval * $pings) ) {
            $pings++;
            $writer->write('<PING/>');
        }

        if ( $s->can_read(0) ) {

            while ( my $line = <$pipe_reader> ) {
                $response .= $line;
            }
        }
    };

    $writer->write('<DONE/>');
    $writer->write($response);
    close $pipe_reader;
    $writer->close();

else {

    #child
    die "cannot fork: $!" unless defined $pid;
    close $pipe_reader;

    #...do writes here...

    close $pipe_writer;
}

关于$writer ，可能与这个问题无关，但是整体解决方案遵循此处第二个代码示例中的模式

由于我们还没有准备好整个HTTP正文，因此我们将回调返回到PSGI，这给了我们$responder对象。 我们只给它HTTP状态和内容类型，然后给我们一个$writer来编写正文。

在上面的代码中，我们使用$writer来编写ping值和最终的正文。 上面的所有代码都在返回给PSGI的回调中，但为简洁起见，我省略了该代码。

Answer 1

这里的第一个问题是非阻塞操作的问题。 其他问题在下面解决。

正如您所引用的，对于select （或IO :: Select ），不应使用缓冲的I / O。 特别是在这里您需要非阻塞和非缓冲的操作。 下面的代码与<>极为混淆。

请注意，“缓冲”是多层业务。 其中一些可以通过简单的程序指令打开/关闭，有些则更难处理，而某些则取决于实现方式。 它包含语言，库，操作系统，硬件。 我们要做的至少是使用推荐的工具。

因此，使用sysread从select操纵的句柄中读取，而不是readline （ <>使用的内容）。 它在EOF上返回0 ，因此可以测试何时关闭写入端（发送EOF时）。

use warnings;
use strict;
use feature 'say';

use Time::HiRes qw(sleep);
use IO::Select; 

my $sel = IO::Select->new;

pipe my $rd, my $wr;
$sel->add($rd); 

my $pid = fork // die "Can't fork: $!";  #/

if ($pid == 0) {
    close $rd; 
    $wr->autoflush;
    for (1..4) {
        sleep 1;
        say "\tsending data";
        say $wr 'a' x (120*1024);
    }
    say "\tClosing writer and exiting";
    close $wr;
    exit; 
}   
close $wr;    
say "Forked and will read from $pid";

my @recd;
READ: while (1) {
    if (my @ready = $sel->can_read(0)) {  # beware of signal handlers
        foreach my $handle (@ready) {
            my $buff;
            my $rv = sysread $handle, $buff, 64*1024;
            if (not $rv) {  # error (undef) or closed writer (==0)
                if (not defined $rv) {
                    warn "Error reading: $!";
                }
                last READ;  # single pipe (see text)
            }
            say "Got ", length $buff, " characters";
            push @recd, length $buff; 
        }
    }
    else {
        say "Doing else ... ";
        sleep 0.5; 
    }
}   
close $rd;
my $gone = waitpid $pid, 0;
say "Reaped pid $gone";
say "Have data: @recd"

假设父级在else节点上不做很多处理， else会使管道检查等待。 在这种情况下，您需要为那些漫长的工作分叉另一个过程。

一些评论

• 我要求sysread提供大量数据，因为这是使用数据的最有效方法，并且您希望孩子从中获得大量写入。 您可以从印刷品中看到效果（下面是一个示例）。

• sysread的未定义返回指示错误。 管道可能仍然可读，并且如果我们返回sysread ， while我们可能会陷入无限的错误循环，因此我们退出循环。 下次可能不会发生读取错误，但指望这样做可能会导致无限循环。

• 在异常返回（写入器关闭或错误）时，代码退出循环，因为此处无需进行其他操作。 但是，对于更复杂的IPC（更多的管道，所有这些都在另一个循环中进行新连接，信号处理程序等），我们需要从要监视的列表中删除该句柄，并且读取错误的处理方式与封闭的作家。

• 在这个简单的示例中，错误处理非常简单（ last READ if not $rv;仅是last READ if not $rv; ）。 但是总的来说，读取错误与顺序关闭的写入器是另一回事，它们是分开处理的。 （对于一个读取错误，我们要重试固定次数。）

• 所有的数据可以被收集到$buff通过使用OFFSET ，第四个参数为sysread ，的length $buff 。 然后，每次写操作都在$buff的末尾开始，并扩展。

   my $rv = sysread $handle, $buff, 64*1024, length $buff; 

  在这种情况下，不需要@recd 。 这是收集数据的常用方法。

• 信号是任何IPC的组成部分。 有限的讨论如下

“安全信号”通常可以保护I / O不受信号中断。 但是选择可能会受到影响

请注意， select是否在信号（例如SIGALRM）发出后重新启动取决于实现。

因此使用它的手柄可能也不安全。 以我的经验，当程序处理SIGCHLD时， can_read可以返回（false）。 这个简单的示例很安全，原因如下：

• 如果can_read在处理信号时返回空，则while将其带回到该句柄，该句柄仍然可读。

• 信号会影响select ，如果涉及的程序被阻止在同时select 。 但是您具有无阻塞操作，并且在select检查手柄时信号正确输入的机会很小

• 最后，我不知道写到管道的进程的SIGCHLD是否会影响该管道另一端的select ，但是即使发生几率天文数字很小。

对于更复杂的代码（如果can_read不直接处于上述循环中），请考虑其错误返回（由于信号）是否会影响程序流程。 如果这是一个问题，请添加代码以检查can_read错误返回； 如果是由信号引起的$! 是EINTR 。 可以使用％来检查！ ，在使用时会加载Errno 。 因此，可以通过if $!{EINTR}来检查can_read是否由于中断而返回。 例如

if (my @ready = $sel->can_read(0)) {
   ...
}
elsif ($!{EINTR}) { 
   # interrupted by signal, transfer control as suitable
   next READ;
}

同样，上面的程序无论如何都会迅速返回while （假设else块不适合长时间运行的工作，因此应该有另一个过程）。

另一个问题是SIGPIPE信号，默认情况下会杀死该程序。 由于您正在处理管道，因此通过安装信号处理程序来谨慎处理它

    $SIG{PIPE} = \&handle_sigpipe;

子handle_sigpipe可以执行程序所需的操作。 例如，设置用于检查管道有效性的全局变量，因此一旦引发错误，我们就不会尝试再次对其进行读写。 我们已分配给$SIG{PIPE}事实可以保护该信号。 但是，除非它是'IGNORE' ，否则can_read必须重新启动can_read 。 请参阅后续文章 。

问题评论

• 您的代码片段将无法“ 继续前进 ”的意图，因为它使用<>阅读。 （此外，您在<>那里停留了while ，它确实会阻塞。因此，一旦读取可用的内容，它就会坐下来，等到更多内容出现。您想要一次读取，但又不要使用<> 。）

• 每个filenahdle都是IO::Handle （或IO::File ）对象，或者至少在需要时被祝福到这些类中。 请参阅此帖子 （第二部分）。

• 关于不将缓冲的I / O与select混合使用的警告与使用它的文件句柄有关。 尽管对于管道至关重要，但写入其他服务无关。

• 代码注释：无需以孩子的出口为条件进行所有工作。 您需要注意孩子何时关闭管道。 稍后重新获取过程（收集信号）。

处理类似需求的另一种方法是用自己的fork工作的每个部分。 因此，要在一个单独的过程中对HTTP进行“保持活动”。 然后，通过使用socketpair进行通信，父进程可以更简单地管理所有子进程。

请参阅此文章以比较read和sysread ，其中包括许多相关点。

---

上面的代码打印

Forked and will read from 4171
Doing else ... 
Doing else ... 
Doing else ... 
        sending data
Got 65536 characters
Got 57345 characters
Doing else ... 
Doing else ... 
        sending data
Got 65536 characters
Got 57345 characters
Doing else ... 
Doing else ... 
        sending data
Doing else ... 
Got 65536 characters
Got 40960 characters
Got 16385 characters
Doing else ... 
Doing else ... 
        sending data
Got 65536 characters
Got 24576 characters
        Closing writer and exiting
Got 32769 characters
Doing else ... 
Reaped pid 4171
Have data: 65536 57345 65536 57345 65536 40960 16385 65536 24576 32769