为什么调用 read() 会永远阻塞答案

【问题标题】：Why does a call to read() block forever为什么调用 read() 会永远阻塞
【发布时间】：2014-02-19 00:58:08
【问题描述】：

我正面临一个最近才开始的令人费解的问题。

我有一个程序使用一个线程写入文件，并使用另一个线程从该文件中读取。两个线程都使用不同的文件描述符。写入线程使用 O_WRONLY 标志打开文件，读取线程以 O_RDONLY 模式打开文件。就逻辑而言，读取线程不知道写入线程在做什么，并且两者都可能使用不同的文件。

写入器线程定期连续写入文件（数据来自设备流，速度高达 20Mbit/s）。

阅读器线程也会定期读取文件。

这是阅读器循环：

while (tot < sz)
{
    LOG(VB_FILE, LOG_DEBUG, LOC +
        QString("read(%1) -- begin").arg(sz-tot));
    ret = read(fd2, (char *)data + tot, sz - tot);
    LOG(VB_FILE, LOG_DEBUG, LOC +
        QString("read(%1) -> %2 end").arg(sz).arg(ret));

    if ((sz - tot) != ret)
    {
        LOG(VB_FILE, LOG_DEBUG, LOC + QString("errno = %1").arg(errno));
    }

    if (ret < 0)
    {
        if (errno == EAGAIN)
        {
            LOG(VB_FILE, LOG_DEBUG, LOC +
                QString("read(%1) -> %2 EAGAIN").arg(sz).arg(ret));
            usleep(1000);
            continue;
        }

        LOG(VB_GENERAL, LOG_ERR,
            LOC + "File I/O problem in 'safe_read()'" + ENO);

        errcnt++;
        numfailures++;
        if (errcnt == 3)
            break;
    }
    else if (ret > 0)
    {
        tot += ret;
    }
    [...snipped...]
}

您可以看到我在调用 read 之前和返回之后显示了一个日志。时不时会调用read，再也回不来了……

2014-02-19 11:24:10.156417 D  TFW(/external/recordings/1001_20140219002351.mpg:64): write(65424) cnt 1 total 5076
2014-02-19 11:24:10.156466 D  TFW(/external/recordings/1001_20140219002351.mpg:64): total written so far: 26934760 bytes
2014-02-19 11:24:10.156514 D  FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(65536) -- begin
2014-02-19 11:24:10.190769 D  FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(65536) -> 60968 end
2014-02-19 11:24:10.190781 I  RingBuf(/external/recordings/1001_20140219002351.mpg): safe_read(...@1698944, 65536) -> 65536, took 60 ms (8.73813Mbps)
2014-02-19 11:24:10.190786 D  RingBuf(/external/recordings/1001_20140219002351.mpg): total read so far: 26930304 bytes
2014-02-19 11:24:10.190795 I  FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(65536) -- begin
2014-02-19 11:24:10.195917 D  FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(65536) -> 4456 end
2014-02-19 11:24:10.195927 D  FileRingBuf(/external/recordings/1001_20140219002351.mpg): errno = 0
2014-02-19 11:24:10.206445 D  TFW(/external/recordings/1001_20140219002351.mpg:64): write(65424) cnt 1 total 1692
2014-02-19 11:24:10.206489 D  TFW(/external/recordings/1001_20140219002351.mpg:64): total written so far: 27000184 bytes
2014-02-19 11:24:10.256103 D  FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(61080) -- begin
2014-02-19 11:24:10.256499 D  TFW(/external/recordings/1001_20140219002351.mpg:64): write(47376) cnt 1 total 40984
2014-02-19 11:24:10.262073 D  TFW(/external/recordings/1001_20140219002351.mpg:64): total written so far: 27047560 bytes
2014-02-19 11:24:10.273385 D  TFW(/external/recordings/1001_20140219002351.mpg:64): write(65424) cnt 1 total 940
2014-02-19 11:24:10.385495 D  TFW(/external/recordings/1001_20140219002351.mpg:64): total written so far: 27112984 bytes

您可以在此处看到写入器已将 26934760 字节写入磁盘。到目前为止的读取已经读取了 26930304 个字节，所以我们距离 EOF 有 4456 个字节。然后尝试读取 64kB，读取几乎立即返回 4456 字节。到现在为止还挺好。立即尝试对 61080 字节 (65536-4456) 进行另一次读取。

不久之后，写线程再次写入文件。 64kB 读取现在永远等待，并且不会再出现 30 多秒。

那么对于为什么读取会突然永远阻塞有什么特别的想法吗？

编辑：从行为来看，一旦读取达到 EOF 并提前返回，如果您在新的写入发生之前立即重试读取，阻塞似乎总是发生。在这种情况下，读取不会退出几秒钟（通常是 20+）

【问题讨论】：

不知道这是否有帮助，但来自man-page for open：NFS 底层协议中有许多不合理之处，其中包括O_SYNC 和O_NDELAY
我不得不评论说，使用 NFS 的应用程序设计不佳，同时写入和读取同一个文件的应用程序也是如此。如果您不需要保留数据，请使用数据库或套接字。
@paddy O_NDELAY（或 O_NONBLOCK）对常规文件应该没有影响。
@EJP 应用程序不必使用 NFS。写入和读取的文件通常为 GB 大小，并且以流式传输直播电视的方式完成。虽然是的，但如果您总是在文件末尾阅读，那么会有更好的方法来做到这一点：意识到您可能不会实时观看直播电视。就像你在看 EOF 后面 5 分钟一样。那么你的伟大设计会做什么呢？缓存 GB 的文件，这样您就不会重新读取它？这是神话电视项目的一部分。您不可能将 GB 的文件放入数据库中。现在那将是糟糕的设计。
那次你说得清楚多了。我没有从原始问题中得到这一点。当人们花时间帮助你解决问题时，尽量不要感到沮丧。你的头在它周围，因为你写了它，而我们其他人不知道你从哪里来，直到你说......所以，正如你描述的问题，当读者试图读取字节时，这会锁定来自正在写入的文件的同一部分。您是否尝试过始终“读取”写入器（以便读取的字节永远不会与写入的字节重叠）？

标签： c++ c linux file-io

【解决方案1】：

好的...

我发现了这个问题以及如何解决它。

如原始问题中所述，一旦读取已达到 EOF、提前返回并立即重试读取（在文件发生新写入之前），似乎总是会发生阻塞。

在这种情况下，read() 不会退出几秒钟（通常超过 20 秒）

因此，解决方法是记录到目前为止我们已经读取了多少字节，以便它知道它在文件中的位置，并调用 fstat 来检查文件的大小。因此，如果我们已经在文件末尾，请确保我们永远不会调用 read() 或要求 read() 检索比文件中更多的字节。

struct stat sb;
off_t current_pos = internalreadpos;

while (tot < sz)
{
    off_t toread = sz - tot;
    bool read_ok = true;

    // check that we have some data to read,
    // so we never attempt to read past the end of file
    // if fstat errored or isn't a regular file, default to previous behavior
    ret = fstat(fd2, &sb);
    if (ret == 0 && S_ISREG(sb.st_mode))
    {
        if (current_pos >= sb.st_size)
        {
            // We're at the end, don't attempt to read
            read_ok = false;
            LOG(VB_FILE, LOG_DEBUG, LOC + "not reading, reached EOF");
        }
        else
        {
            toread = min(sb.st_size - current_pos, toread);
            if (toread < (sz-tot))
            {
                LOG(VB_FILE, LOG_DEBUG,
                    LOC + QString("About to reach EOF, reading %1 wanted %2")
                    .arg(toread).arg(sz-tot));
            }
        }
    }

    if (read_ok)
    {
        LOG(VB_FILE, LOG_DEBUG, LOC +
            QString("read(%1) -- begin").arg(toread));
        ret = read(fd2, (char *)data + tot, toread);
        LOG(VB_FILE, LOG_DEBUG, LOC +
            QString("read(%1) -> %2 end").arg(toread).arg(ret));
    }
    if (ret < 0)
    {
        if (errno == EAGAIN)
            continue;

        LOG(VB_GENERAL, LOG_ERR,
            LOC + "File I/O problem in 'safe_read()'" + ENO);

        errcnt++;
        numfailures++;
        if (errcnt == 3)
            break;
    }
    else if (ret > 0)
    {
        tot += ret;
        current_pos += ret;
    }

    if (oldfile)
        break;

    if (ret == 0) // EOF returns 0
    {
        if (tot > 0)
            break;

        zerocnt++;

        // 0.36 second timeout for livetvchain with usleep(60000),
        // or 2.4 seconds if it's a new file less than 30 minutes old.
        if (zerocnt >= (livetvchain ? 6 : 40))
        {
            break;
        }
    }

【讨论】：