gpt4 book ai didi

c++ - 为什么对 read() 的调用会永远阻塞

转载 作者:IT王子 更新时间:2023-10-29 00:37:56 25 4
gpt4 key购买 nike

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

我有一个程序,它使用一个线程写入一个文件,另一个线程从该文件中读取。两个线程都使用不同的文件描述符。写入线程使用 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 并提前返回时发生。在这种情况下,read 会持续数秒(通常为 20+)才会退出

最佳答案

好的...

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

如原始问题中所述,一旦读取到达 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;
}
}

关于c++ - 为什么对 read() 的调用会永远阻塞,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21868812/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com