sysread 返回 undef，errno 是 EINVAL，但是工作吗？

Question

我为系统事件文件的非阻塞输入设置了一些代码。

sysopen(FILE, $targetInput, O_NONBLOCK|O_RDONLY) or die "Failed to open $targetInput, quitting.\n";
binmode(FILE);


#More assignments and preparations here...

while (1) {

    #Code that justifies non-blocking I/O here...

    $rBytes = sysread(FILE, $buffer, 16);

    printf("%d vs %d\n", $!, EAGAIN);       
    print defined($rBytes) ? "Defined!\n" : "Undef!\n";


    if (!defined($rBytes) && $! == EAGAIN) {
        #Nothing actually read in non-blocking mode:
        usleep(1000);
    } else {
        #Got an event, moving on:
        print "Got it!\n";
        print "$rBytes!\n";
        last;
    }

}

#Logic using $buffer here...

这是一个非常标准的设置，有几十个例子可以用于这个东西。但是，我发现 100% 的时间，$rBytes 仍未定义，$! 设置为代码 22，EINVAL（无效参数）。已经进行了大量测试，以确保是 sysread 函数专门导致了这种情况，而在此之前绝对没有。

关键是，它有效。如您所见，我的代码假定任何 not 组合的 $rBytes 未定义（始终为真）和 $! 为 EAGAIN（始终为假）只是假设一切都很好，因为我没有添加任何错误处理。这个代码块后面是一个巨大的开关/案例；不存在的数据“无害地”通过它，循环返回以尽可能快地再次执行。

当接收到有效输入时，$rBytes仍然未定义。但是由于$! 仍然不是EAGAIN，它也传递给程序的其余部分并按预期准确运行，$buffer 包含它应该包含的内容。如果我不看一下我的 CPU 使用率计，我实际上根本不会注意到这个问题，如果它是一个快速的一次性脚本，我可能不会尝试修复它。

我可以肯定地说，“无效论点”的指控是虚假的。问题是，为什么它会给出那个错误代码，为什么$rBytes总是未定义？

Answer 1

当我正在拼凑一个快速脚本来模拟迄今为止所做的假设时，我实际上自己偶然发现了答案；果然，所有必要的信息一直都在问题中。

典型的系统事件文件处理长度为 24 字节的消息。当然，这段代码试图从这些事件中提取 16 位时间戳，并将其余部分留待以后使用。由于我自己不理解的原因，sysread 不喜欢那样。

通过确保所需的长度大于或等于 24，sysread 将报告已读取的字节数和$! 记录的内容。 24 可能是一个幻数，或者它可能只是在从非阻塞资源中读取部分消息时出现问题（在阻塞模式下不会发生错误）。它仍在将适当的数据放入$buffer，大概是因为底层代码通过引用传递它并且在发生错误时不会将其归零，这就是显示块之后的一切正常的原因。