Data.table: SHM 尺寸超出错误

功能请求，检查 /dev/shm 的大小以查看它是否与 mmap 大小匹配。 在我的例子中，我在 docker 容器中使用 R 并且 /dev/shm 的默认大小是 64M。 当代码在管道流上执行 mmap 时（例如使用 hadoop fs -cat /myfile.csv），它只会将管道中的 shm 大小字节读取到 mmap 中。 它不会通过我怀疑是正常的 C api 报告错误。 然而，调试 fread 抱怨文件格式的原因导致深入研究 data.table 的 R 和 C 代码，发现它使用了这种机制。 报告的错误（随机消息基于我的管道恰好被切断的位置）：

 (ERROR):Expected sep (',') but ' ' ends field 0 when detecting types from point 10: 14183667

这可以通过执行以下操作来重现：

• 构建一个比 /dev/shm 大约 5 兆的文件
• 将 /dev/shm 调整为 64M（这是 Docker 容器的默认值）
• 在“cat ~/myfile.csv”上运行 fread <-- cat 创建管道
• 码头工人 V1.12+
• 来自 docker hub 的 Centos 最新镜像
• R-open v3.4.0 (微软)

在代码中： https ://github.com/Rdatatable/data.table/blob/master/src/fread.c
在第 788 行附近，它可能应该检查 /dev/shm 的大小以查看它是否与刚刚读入内存的文件匹配。 在我的 docker 案例中，这里是失败测试条件的详细输出：

 > dat.df3<-fread("/opt/cloudera/parcels/CDH/bin/hadoop fs -cat /user/tcederquist/tim_pop_comm_14_5 | head -3668850" ,sep=",", header=TRUE, verbose=TRUE)
 Input contains no \n. Taking this to be a filename to open
 File opened, filesize is 0.062500 GB.
 Memory mapping ... ok
 ....basic output
 Type codes (point  8): 1111
 Type codes (point  9): 1111
 (ERROR):Expected sep (',') but ' ' ends field 0 when detecting types from point 10: 14183667

预期成绩：

 File opened, filesize is 0.373524 GB.

此外，当它失败时，它会在内部知道行号和失败时的其他有用信息。 在发现详细标志之前，我必须手动将值归零。 如果正常的错误消息指示第 # 行，那就太好了。 vebose=T 在计算分隔符 # 时显示位置，例如对于此测试用例，错误输出会很有用（因为我知道该文件有 20M 条记录）：

 Count of eol: 3668839 (including 0 at the end)
 nrow = MIN( nsep [11006514] / (ncol [4] -1), neol [3668839] - endblanks [0] ) = 3668838